Skip to content

Feed aggregator

Creating a Lean-Based Agile Experience

TV Agile - Tue, 01/13/2015 - 19:49
This presentation explores the connection between Lean and Agile. Video source: https://ocio.wa.gov/news/agile-fridays-training-series-agile-development
Categories: Blogs

The Agile Manifesto – Essay 2: Individuals and Interactions over Processes and Tools

Learn more about our Scrum and Agile training sessions on WorldMindware.com

This value is the hardest to do well.

In IT and high-tech, there is a “natural” prevailing culture that makes this first value incredibly difficult.  This difficulty is rooted in traditional “scientific management“, but made even more so by a critical additional factor that is mostly invisible: techies solve problems with tools.

Management wants to define processes with clearly described activities, clear inputs and outputs, and clear sources and recipients of the activity (see the description of SIPOC for an explanation of this thinking).  Techies build tools to automate these well-defined processes to improve their efficiency, quality and reliability.

Management creates organizational roles with detailed descriptions, detailed goals and detailed performance measurements (see the description of RACI for an explanation of this thinking).  Techies build tools to carefully constrain people to these detailed roles to improve efficiency, quality and reliability.

Management has money.  Techies want some of that money.  So they build the tools to help management get what they really want: a completely automated organization of computers, machines and robots.

The culture of technology is to solve problems with individuals and interactions by introducing processes and tools.  The culture of technology is (almost) inherently anti-Agile.

Ford Assembly Line 1913

The culture of technology is to solve problems with individuals and interactions by introducing processes and tools.  The culture of technology is (almost) inherently anti-Agile.

 

BMW Assembly Line

Individuals and Interactions

Let’s look at the first part of this value in a bit more depth.  When we think about work, most of us work with other people.  We bring our unique skills, personality and interests to work, and we work with other people who also bring unique skills, personality and interests.  In a high-bureaucracy, high-technology work environment, it is easy to forget about all this uniqueness and instead objectify people.  When people sense they are being objectified, mostly they feel bad about it.  We want to be acknowledged as thinking, feeling, unique beings with agency.  Objectification, no matter the source or the rationale, is depressing and de-humanizing.  The Agile Manifesto implicitly recognizes this concept and asks us who follow the Manifesto to try to shift our value-focus.

There are many aspects to this concept of humanizing work.  Some things that come to mind immediately include recognizing and encouraging people’s capacity for:

  • creativity and innovation
  • learning and problem-solving
  • caring about others
  • pride in work
  • complementarity with others
  • responsibility

Photo of diverse children teamwork

Processes and Tools

This side of the value is also interesting.  Processes and tools do not have agency.  They do not improve on their own.  Instead, processes and tools only either remain the same or degrade.  Processes and tools are forces for stasis: they encourage maintenance of the status quo.  Only humans introduce new processes and tools.

Technologists live in a philosophical double-standard: we build processes and tools for others to use and which we frequently would not like used on ourselves.  (We will discuss the cases where me might both build and benefit from processes and tools in a bit.)  This is one of the challenges of the type of work we do in technology, but it also applies to many other types of work.  So how do we solve this conundrum?  I would assert that the principles of the Agile Manifesto and the various Agile methods and techniques are all answers to this question.  They show us possible ways to implement this value (and the others) without getting stuck in processes and tools.

Only humans introduce new processes and tools.

 

What are Processes Good For, What are Tools Good For?

Some processes are good.  Some amount of process is good.  How do we determine what is good?  Well, it largely depends on context.  Some examples:

If a close family member is living in a distant location then the advances in communication tools are extremely helpful: the telegraph, the telephone, the cell phone, email, Skype.  These tools create connections where otherwise there would be little or none.

If a great deal of data is created while running a marketing campaign and needs to be stored and manipulated, then computers are amazing tools for this.  Computers are much much better than human minds and manual record-keeping for this sort of work.

If you create a fantastic new soup, from scratch, for some special occasion and you want to remember how to make and even share how to make it with others, then you document the process in a recipe.

Photo of Pho Soup

Context, Emphasis and Crisis

Context here is important.  The value of Individuals and Interactions over Processes and Tools is basically a statement that given the right circumstances we can use processes and tools, but that our default approach to work and problem-solving should be to focus on individuals and their interactions.  Depending on the state of your work environment this is easier or harder.

For example, a startup company founded by three long-time friends who have not yet employed anyone else is almost certainly going to solve most problems that come up through discussion amongst founders and through the development of their skills and capabilities.  As a company gets larger, however, there is pressure to adopt more and more processes and tools.  This pressure comes from a deep source: lack of trust.  At about 12 people, you reach the limit of the number of people you can have and still have anyone do anything (this limit is referred to obliquely in “The Wisdom of Teams” by Katzenbach and Smith).  After 12 people, it becomes harder to avoid role specialization and some basic forms of processes and tools.  In other words, bureaucracy starts growing as the organization grows.  Even at this size, however, it is still relatively easy to have a very strong emphasis on individuals and interactions.  There is another important limit: somewhere around 150 to 200 people, any hope of 100% mutual trust among the members of the organization is lost.  This is the point at which processes and tools “naturally” start to truly take over.  (This transition can happen even in much smaller organizations if the culture does not emphasize trust-based interactions.)

In small trust-based organizations, crisis is usually addressed by the mechanisms of mutual respect, skill development, informal agreements, and strengthening the interactions between people.  In a large organization with low trust, crisis is almost always addressed by the creation of new bureaucracy: sign-offs, audits, traceability, procedures, policies, processes and tools.

The true test of the an organization’s commitment to the first value of the Agile Manifesto is, therefore, how it responds to crisis.  When someone makes a mistake, can we help them develop the skill and the support networks to avoid the mistake in the future?  Or do we put in place even more restrictive constraints on what that person does and how they do it?

In a large organization with low trust, crisis is almost always addressed by the creation of new bureaucracy.

 

Beyond IT and High-Tech

For now, all that needs to be said is that this particular value of the Agile Manifesto does not in any way directly refer to software or software development.  As such, it is pretty easy to see how it could be applied in many other types of work.  However, there are some types of work where processes and tools really do take precedence over individuals and interactions.  If we want to apply the concepts of Agile universally (or near-universally), we have to examine some of these exceptions.  I will leave that for a future essay.

In the next few articles, I will continue to look in-depth at each of the values of the Agile Manifesto.  If you missed the first essay in this series, please check it out here: The Agile Manifesto – Essay 1: Value and Values.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories: Blogs

The Mindful Ohno

Evolving Excellence - Tue, 01/13/2015 - 18:50

Empire State PigeonMindfulness has become all the rage in personal and professional leadership these days, which is good and bad. Understood and done right, it is a very powerful concept. But as with most concepts it is also often misunderstood, therefore sometimes maligned, and even misapplied. Somewhat similar to lean, which is also a powerful concept, with supporting tools that must be appropriately leveraged in conjunction with a system that includes people with brains (really!), otherwise it often fails. And is therefore sometimes maligned.

Mindfulness is simply becoming aware.  Taking the time to slow down, look around, analyze context, and based on that new awareness, improve.  It isn't just calming the mind, although that can be a key component, it isn't prayer, it isn't contemplation, it isn't dreaming or getting lost in thought.  It is not dwelling on the past, not planning on the future, but being purposely present right here, right now, with what is truly important.

I first discovered the concept many years ago during a time of intense personal and professional stress.  I developed a habit of escaping to Hawaii on literally a couple hours' notice, embracing quietude and solitude to let my racing thoughts settle so the important ones could be analyzed.  I was amazed at how some of my perspectives and opinions changed, how unexpectedly wrong they had been before, and how that newfound knowledge freed me to become calm and engaged.

Mindful meditation is one of many forms of meditation where you focus on becoming aware of your thoughts, usually by working to slow the torrent so that individual thoughts can be noticed, analyzed, and considered.  Those new to the process are usually shocked at just how many thoughts are flowing through their heads, the distortions created both by perhaps skewed perspectives and the interaction with other thoughts, and therefore just how difficult this form of meditation is.  As with lean, the process is especially powerful when, after considerable practice, the new knowledge and awareness is coupled with a framework to create and support change.  The physiological changes in the brain created by meditation are rather astounding.

Mindful leadership starts to focus a bit more externally, but still with an awareness of the impact and influence of individual action in the present.  What is the present situation, what am I listening to, are my perspectives correct, what is the problem, what should I be working on, why is my opinion what it is?  Right here, right now.

One area where I try to leverage this is with email.  Colleagues know that I used to be (and when I fail, still am) a master of the long-winded flaming email.  Nowadays when someone pushes one of my buttons I try hard to take a step back.  Why is the topic a hot button for me?  Why do I have such a strong opinion?  Is my opinion correct, or is my perspective skewed? Do I have all the data?  Is it really an important enough topic to take a strong stand? And finally, if it still is important, is there a better way to convey my opinion?  I think I've improved, but admittedly I still struggle.

Taiichi Ohno is famous for sending students to the shop floor with instructions to just stand and observe - for at least a half hour.  Coincidentally that's about how long it takes for the mind to calm after some experience with meditation.  Just observing is difficult.  We want to jump to analysis and improvement.  But as Ohno was trying to point out, first you must simply observe, become aware of the process, become aware of what is going on that you probably didn't notice when rushing to and fro on factory floor.  Only then can you truly see the process in the present moment, understand what's important right now and how perspectives can be biased, and begin to formulate plans for improvement.

It starts with simple observation.  Whether it's the thoughts in your mind, your actions as a leader, or the process you're involved with.  Perhaps even a restaurant you're dining at, as I witnessed in Bangkok a couple years ago.

Take the time to simply observe. You may be surprised at what you discover.

Categories: Blogs

Is Constant Process Improvement Imperative?

Scrum Expert - Tue, 01/13/2015 - 18:48
This article examines the Agile myth that constant process improvement is imperative. It discusses the fact that if you need to continuously observe your process, you should wait for the pauses between iteration to perform process improvement. Paul Raymond, Inflectra Corporation, http://www.inflectra.com/ In days gone by, when projects were slow, lumbering proceedings, process improvement could only be implemented once a project was finished. Trying to evolve a methodology midstream was too disruptive because processes were overly complex, excessively detailed and heavily documented. In theory, following the process was mandatory but, rules don’t ...
Categories: Communities

Does Agile Apply to Your Project?

Johanna Rothman - Tue, 01/13/2015 - 15:49

I have a new column posted at projectmanagement.com. It’s called Does Agile Apply to Your Project? (You might need a free registration.)

 

Categories: Blogs

Proactive vs Reactive Customer Service

Growing Agile - Tue, 01/13/2015 - 15:00

I’m the type of customer who let’s a company know what I think of their service via twitter. Recently I’ve started to notice that there are really two types of companies in terms of how they deal with customer complaints. I think of them as proactive and reactive. Let me give you an example.

Imagine a customer complains on twitter that the queue in your bank branch is too long.

A proactive organisation, might use the location information in that tweet to see which branch the customer is in, then call that branch manager and find out if there is a problem and if so how it can be addressed, maybe some staff can be redirected, maybe the queue can be split into those with quick standard requests and those with more complex requests.

Image the customer surprise when you text them back and say “Thanks for the feedback, we’ve quickly reshuffled some staff, and your queuing time should now be reduced to 5 minutes. Thanks for bringing this to our attention”.

Here is a real life example of customer delight. Recently we’ve started using StreamScience. We got an email saying they would love to hear any ideas we have for new features. We had one, and emailed them back. We got an immediate reply that it was a great idea, and easy to do, so it would be implemented. Imagine my surprise when they mailed me a few days later to let me know the feature was done and I could now use it!

Unfortunately it is a much more common occurrence that I see the more reactive form of customer service.

Recently I observed someone tweeting their frustration about a company’s security questions for authenticating you at the call center. The question was about which of their products you use. Something that most customers, me included, don’t actually know. I don’t know what kind of internet hosting package I have for example, I expect my provider to know that.

It was made worse because the company mentioned then tweeted asking how they could help. To me it was obvious how they could help. They could change the security questions, and then tweet back that they had done that. But instead they chose to ask a question that doesn’t really have any response except ‘fix what I already told you was broken’.

Asking how you can help is not good customer service. Anticipating your customer needs and solving their problems before they even need to ask, now that is proactive customer service.

Think about your own organisations customer service? Where do you stand? How can you anticipate your customer needs better?

 

Categories: Companies

New SAFe Interview on InfoQ

Agile Product Owner - Tue, 01/13/2015 - 10:19

Hi Folks,

“this just in”, check out:

http://www.infoq.com/news/2015/01/lean-agile-leadership-safe

 

Categories: Blogs

Was bringt Scrum eigentlich dem Fachbereich?

Scrum 4 You - Tue, 01/13/2015 - 08:30

Die Einführung von Scrum verlagert sich immer mehr in die Entwicklungsabteilungen von großen Konzernen. Die Vielzahl unserer Transitionsprojekte zeigt, dass die Scrum-Teams intensiv mit dem Fachbereich als internem Kunden (und oft auch Nutzer) zusammenarbeiten müssen. Da Scrum eine Produktentwicklungsmethode abbildet und somit auf die Kundenzufriedenheit ausgerichtet ist, ist es wichtig, den Fachbereich gut abzuholen und ihn über Scrum zu informieren. Immerhin birgt jegliche Veränderung auch eine Möglichkeit der Verschlechterung in sich und diese Bedenken gilt es aus dem Weg zu räumen. Um die Brücke zwischen Management, Technikern und Produktmanagern zum Fachbereich zu schlagen, habe ich ein paar Aspekte zusammengetragen, die für jeden Fachbereichsmitarbeiter bei der Einführung von Scrum wichtig zu wissen wären.

Als Fachbereichsmitarbeiter finde ich Scrum toll, weil…
  • Scrum orientiert sich am Kunden (ROI) und Benutzer (Qualität und Usability), d.h. mein Interesse und Input stehen im Mittelpunkt.
  • Die Transparenz über den Projektstatus und die Priorisierung meiner Anforderungen im Product Backlog ermöglichen es mir jederzeit zu wissen, wann ich welche Funktionalität erhalten werde.
  • Die Priorisierung des Backlogs nach Return On Investment und somit Businesswert stellt sicher, dass die Ressourcen für die wertvollste Entwicklung investiert werden. Und das Tolle ist, ich habe jederzeit die Möglichkeit zu sagen: “Danke. Ich habe ausreichend Funktionalitäten erhalten.” Das könnte mir viel Budget sparen.
  • Die feste Zusammensetzung des Scrum-Teams und der kontinuierliche Austausch mit mir steigern die Verantwortung der Entwickler, eine hohe Qualität zu liefern.
  • Dank der klaren Rollenaufteilung weiß ich genau, wer im Scrum-Team welche Aufgaben und Verantwortungen hat, und wen ich in welchem Fall ansprechen sollte. Prinzipiell ist der Product Owner meine erste Anlaufstelle.
  • Die Rolle des ScrumMasters ist großartig, da ich aufgrund der langfristigen Produktivitätssteigerung Geld sparen bzw. mehr Funktionalität bekommen werde.
  • Ich habe spätestens alle 2 Wochen die Möglichkeit, Feedback zu einem fertigen Produktinkrement zu geben.
  • Produktentscheidungen werden erst dann getroffen, wenn ausreichend Informationen da sind und es wirklich notwendig ist (bei Sprintstart statt Projektstart).
  • Ich habe bei Projektstart keinen Stress mehr, Spezifikationen zu erstellen, die vor Projektende vermutlich schon wieder veraltet sein werden.
  • Das Sprint Planning 1 gibt mir ein Forum, in dem ich den Kontext und Hintergrund meiner Anforderungen erklären kann. Durch die Möglichkeit der Rückfragen gibt es weniger Missverständnisse und am Ende des Sprints erhalte ich tatsächlich das, was ich wollte. Sollte dem nicht so sein, erkennen wir spätestens 2 Wochen später schon im Sprint Review durch mein Feedback, dass wir aneinander vorbei kommuniziert haben. Dann habe ich im schlimmsten Fall 2 Wochen an Geld verloren. Das tut weh, ist aber immer noch besser als eine gesamte Projektdauer lang auf einer falschen Anforderung aufzubauen.
  • Change Request Prozesse sind tot. Halleluja. Stattdessen spreche ich direkt mit dem Product Owner und die Umsetzung kann für den nächsten Sprint (spätestens in 2 Wochen) eingeplant werden.
  • Langfristig müssen meine Kollegen und ich nicht mehr die fachlichen Tests durchführen, da die Verantwortung für die Qualität vermehrt beim Dev.Team liegen soll. Falls wir dennoch testen müssen, können wir uns die Zeit besser einplanen, da die Releasezyklen immer kürzer, die Sprints vorhersehbar und der Umfang überschaubar sind.
Als Fachbereichsmitarbeiter muss ich mich erst an Scrum gewöhnen, weil…
  • Jeder Sprint ist geschützt. D.h. meine persönlichen Kontakte zu den Entwicklern nutzen mir nichts mehr – ScrumMaster und Product Owner achten darauf, dass auch eingehalten wird, wozu sich das Team am Anfang des Sprints verpflichtet (“committed”) hat. Aber so tragisch ist das nicht: Das betrifft ohnedies nur neue Funktionalitäten und da kann ich ruhig bis zum nächsten Sprint (max. 2 Wochen) warten. Fehler haben in Scrum weiterhin höchste Prio und werden sofort bearbeitet.
  • Die Priorisierung des Product Backlogs liegt in den Händen des Product Owners und ist nach Businesswert geregelt. D.h. wenn mir wenig Budget zur Verfügung steht und meine Anforderung dem Produkt bzw. Unternehmen keinen wirklichen Mehrwert bringen wird, kann es sein, dass sie erst sehr spät bzw. nie umgesetzt werden wird. Ob das tatsächlich schlimm ist, steht zur Debatte.
Als Fachbereichsmitarbeiter wird sich meine Zusammenarbeit mit dem Scrum-Team folgendermaßen gestalten…
  • Bei der Durchführung von fachlichen Tests wäre es gut, im Scrum-Teamraum zu sitzen und jeweils mit einem Dev.Teammitglied gepaart zu arbeiten. Somit besteht die Möglichkeit, automatisch voneinander zu lernen (“Learning by Doing”), die Anwendung des Produkts aus Benutzersicht besser kennenzulernen, und mich somit langfristig als fachlichen Tester zu entlasten bzw. abzulösen.
  • Ich sollte mich regelmäßig (Empfehlung: 1x wöchentlich) mit dem Product Owner treffen, um das Product Backlog mit meinen neuesten Anforderungen, Änderungswünschen und Ideen zu füttern und über den Status der schon bekannten Anforderungen zu sprechen.
  • Im Sprint Planning 1 am Anfang jedes Sprints stehe ich zur Verfügung, um meine Anforderungen an das Produktinkrement in einem Kontext und mit mehr Details dem Scrum-Team zu erklären (Workflow, Unternehmensstrategie, Ziele, Endnutzer etc.). Das hilft ungemein, um die Bilder in unseren Köpfen abzugleichen und sicherzustellen, dass am Ende auch das rauskommt, was ich in Auftrag gebe.
  • Das Scrum-Team und ich freuen uns, wenn ich es schaffe, alle zwei Wochen im Sprint Review dabei zu sein. Hier bekomme ich nämlich das Produktinkrement (meine gewünschte Funktionalität) gezeigt, darf es selbst mal ausprobieren und kann Feedback geben.
  • Ab und zu ruft mich das Scrum-Team während des Sprints an, um Details bzgl. der aktuellen Anforderungen zu klären. Das ist mir lieber, als nichts von ihnen zu hören und dann unzufrieden mit dem Ergebnis zu sein.

Diese Liste ist definitiv nicht vollständig und variiert je nach Unternehmenskontext. Dennoch sollte sie einen Ansatzpunkt für eine Schulung des Fachbereichs zum Thema Scrum und agiles Arbeiten bieten. Ich hoffe, diese Aufzählung hilft und freue mich über euer Feedback!

Categories: Blogs

Generic variance in DI containers

Jimmy Bogard - Tue, 01/13/2015 - 03:02

DI containers, as complex as they might be, still provide quite a lot of value when it comes to defining and realizing the composition of your system. I use the variance features quite a bit, especially in my MediatR project and composing a rich pipeline. A side note, one of the design goals of MediatR is not to take any dependency on a 3rd party DI container. I instead take a dependency on Common Service Locator, which all major DI containers already have. As part of this exercise, I still wanted to provide examples of all major containers, and this led me to figure out which containers supported what.

I looked at the major containers out there:

  • Autofac
  • Ninject
  • Simple Injector
  • StructureMap
  • Unity
  • Windsor

And tried to build examples of using MediatR. As part of this, I was able to see what containers supported which scenarios, and how difficult it was to achieve this.

The scenario is this: I have an interface, IMediator, in which I can send a single request/response or a notification to multiple recipients:

public interface IMediator
{
    TResponse Send<TResponse>(IRequest<TResponse> request);

    Task<TResponse> SendAsync<TResponse>(IAsyncRequest<TResponse> request);

    void Publish<TNotification>(TNotification notification)
        where TNotification : INotification;

    Task PublishAsync<TNotification>(TNotification notification)
        where TNotification : IAsyncNotification;
}

I then created a base set of requests/responses/notifications:

public class Ping : IRequest<Pong>
{
    public string Message { get; set; }
}
public class Pong
{
    public string Message { get; set; }
}
public class PingAsync : IAsyncRequest<Pong>
{
    public string Message { get; set; }
}
public class Pinged : INotification { }
public class PingedAsync : IAsyncNotification { }

I was interested in looking at a few things with regards to container support for generics:

  • Setup for open generics (registering IRequestHandler<,> easily)
  • Setup for multiple registrations of open generics (two or more INotificationHandlers)
  • Setup for generic variance (registering handlers for base INotification/creating request pipelines)

My handlers are pretty straightforward, they just output to console:

public class PingHandler : IRequestHandler<Ping, Pong> { /* Impl */ }
public class PingAsyncHandler : IAsyncRequestHandler<PingAsync, Pong> { /* Impl */ }

public class PingedHandler : INotificationHandler<Pinged> { /* Impl */ }
public class PingedAlsoHandler : INotificationHandler<Pinged> { /* Impl */ }
public class GenericHandler : INotificationHandler<INotification> { /* Impl */ }

public class PingedAsyncHandler : IAsyncNotificationHandler<PingedAsync> { /* Impl */ }
public class PingedAlsoAsyncHandler : IAsyncNotificationHandler<PingedAsync> { /* Impl */ }

I should see a total of seven messages output from the result of the run. Let’s see how the different containers stack up!

Autofac

Autofac has been around for quite a bit, and has extensive support for generics and variance. The configuration for Autofac is:

var builder = new ContainerBuilder();
builder.RegisterSource(new ContravariantRegistrationSource());
builder.RegisterAssemblyTypes(typeof (IMediator).Assembly).AsImplementedInterfaces();
builder.RegisterAssemblyTypes(typeof (Ping).Assembly).AsImplementedInterfaces();

Autofac does require us to explicitly add a registration source for recognizing contravariant interfaces (covariant is a lot rarer, so I’m ignoring that for now). With minimal configuration, Autofac scored perfectly and output all the messages.

Open generics: yes, implicitly

Multiple open generics: yes, implicitly

Generic contravariance: yes, explicitly

Ninject

Ninject has also been around for quite a while, and also has extensive support for generics. The configuration for Ninject looks like:

var kernel = new StandardKernel();
kernel.Components.Add<IBindingResolver, ContravariantBindingResolver>();
kernel.Bind(scan => scan.FromAssemblyContaining<IMediator>()
    .SelectAllClasses()
    .BindDefaultInterface());
kernel.Bind(scan => scan.FromAssemblyContaining<Ping>()
    .SelectAllClasses()
    .BindAllInterfaces());
kernel.Bind<TextWriter>().ToConstant(Console.Out);

Ninject was able to display all the messages, and the configuration looks very similar to Autofac. However, that “ContravariantBindingResolver” is not built in to Ninject and is something you’ll have to spelunk Stack Overflow to figure out. It’s somewhat possible when you have one generic parameter, but for multiple it gets a lot harder. I won’t embed the gist as it’s quite ugly, but you can find the full resolver here.

Open generics: yes, implicitly

Multiple open generics: yes, implicitly

Generic contravariance: yes, with user-built extensions

Simple Injector

Simple Injector is a bit of an upstart from the same folks behind NancyFx someone not related to NancyFx at all yet has a very similar Twitter handle, and it focuses really on the simple, straightforward scenarios. This is the first container that requires a bit more to hook up:

var container = new Container();
var assemblies = GetAssemblies().ToArray();
container.Register<IMediator, Mediator>();
container.RegisterManyForOpenGeneric(typeof(IRequestHandler<,>), assemblies);
container.RegisterManyForOpenGeneric(typeof(IAsyncRequestHandler<,>), assemblies);
container.RegisterManyForOpenGeneric(typeof(INotificationHandler<>), container.RegisterAll, assemblies);
container.RegisterManyForOpenGeneric(typeof(IAsyncNotificationHandler<>), container.RegisterAll, assemblies);

While multiple open generics is supported, contravariance is not. In fact, to hook up contravariance requires quite a few hoops to jump through to set it up. It’s documented, but I wouldn’t call it “out of the box” because you have to build your own wrapper around the handlers to manually figure out the handlers to call. UPDATE: as of 2.7, contravariance *is* supported out-of-the-box. Configuration is the same as it is above, the variance now “just works”.

Open generics: yes, explicitly

Multiple open generics: yes, explicitly

Generic contravariance: no yes, implicitly

StructureMap

This is the most established container in this list, and one I’ve used the most personally. StructureMap is a little bit different in that it applies conventions during scanning assemblies to determine how to wire requests for types up. Here’s the StructureMap configuration:

var container = new Container(cfg =>
{
    cfg.Scan(scanner =>
    {
        scanner.AssemblyContainingType<Ping>();
        scanner.AssemblyContainingType<IMediator>();
        scanner.WithDefaultConventions();
        scanner.AddAllTypesOf(typeof(IRequestHandler<,>));
        scanner.AddAllTypesOf(typeof(IAsyncRequestHandler<,>));
        scanner.AddAllTypesOf(typeof(INotificationHandler<>));
        scanner.AddAllTypesOf(typeof(IAsyncNotificationHandler<>));
    });
});

I do have to manually wire up the open generics in this case.

Open generics: yes, explicitly

Multiple open generics: yes, explicitly

Generic contravariance: yes, implicitly

Unity

And now for the most annoying container I had to deal with. Unity doesn’t like one type registered with two implementations, so you have to do extra work to even be able to run the application with multiple handlers for a message. My Unity configuration is:

container.RegisterTypes(AllClasses.FromAssemblies(typeof(Ping).Assembly),
   WithMappings.FromAllInterfaces,
   GetName,
   GetLifetimeManager);

/* later down */

static bool IsNotificationHandler(Type type)
{
    return type.GetInterfaces().Any(x => x.IsGenericType && (x.GetGenericTypeDefinition() == typeof(INotificationHandler<>) || x.GetGenericTypeDefinition() == typeof(IAsyncNotificationHandler<>)));
}

static LifetimeManager GetLifetimeManager(Type type)
{
    return IsNotificationHandler(type) ? new ContainerControlledLifetimeManager() : null;
}

static string GetName(Type type)
{
    return IsNotificationHandler(type) ? string.Format("HandlerFor" + type.Name) : string.Empty;
}

Yikes. Unity handles the very simple case of open generics, but that’s about it.

Open generics: yes, implicitly

Multiple open generics: yes, with user-built extension

Generic contravariance: derp

Windsor

The last container in this completely unnecessarily long list is Windsor. Windsor was a bit funny, it required a lot more configuration than others, but it was configuration that was built in and very wordy. My Windsor configuration is:

var container = new WindsorContainer();
container.Register(Classes.FromAssemblyContaining<IMediator>().Pick().WithServiceAllInterfaces());
container.Register(Classes.FromAssemblyContaining<Ping>().Pick().WithServiceAllInterfaces());
container.Kernel.AddHandlersFilter(new ContravariantFilter());

Similar to Ninject, the simple scenarios are built-in, but the more complex need a bit of Stack Overflow spelunking. The “ContravariantFilter” is very similar to the Ninject implementation, with the same limitations as well.

Open generics: yes, implicitly

Multiple open generics: yes, implicitly

Generic contravariance: yes, with user-built extension

Final score

Going in, I thought the containers would be closer in ability for a feature like these that are pretty popular these days. Instead, they’re miles apart. I originally was going to use this as a post to complain that there are too many DI containers in the .NET space, but honestly, the feature set and underlying models are so completely different it would take quite a bit of effort to try to consolidate and combine projects.

What is pretty clear from my experience here is that Unity as a choice is probably a mistake.

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

Categories: Blogs

Python: Counter – ValueError: too many values to unpack

Mark Needham - Tue, 01/13/2015 - 01:16

I recently came across Python’s Counter tool which makes it really easy to count the number of occurrences of items in a list.

In my case I was trying to work out how many times words occurred in a corpus so I had something like the following:

>> from collections import Counter
>> counter = Counter(["word1", "word2", "word3", "word1"])
>> print counter
Counter({'word1': 2, 'word3': 1, 'word2': 1})

I wanted to write a for loop to iterate over the counter and print the (key, value) pairs and started with the following:

>>> for key, value in counter:
...   print key, value
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: too many values to unpack

I’m not sure why I expected this to work but in fact since Counter is a sub class of dict we need to call iteritems to get an iterator of pairs rather than just keys.

The following does the job:

>>> for key, value in counter.iteritems():
...   print key, value
...
word1 2
word3 1
word2 1

Hopefully future Mark will remember this!

Categories: Blogs

SAFe LSE Quick update

Agile Product Owner - Mon, 01/12/2015 - 18:53

Well, we’ve (Harry, Dean, Alex and Inbar) been laboring mightily to develop all the new content for SAFe LSE. (Turns out, it’s hard). One result is the 50th (yes, version 50) of the LSE Big Picture.

(Speaking of laboring, Inbar’s wife just delivered twins to the family. I think he now has five kids under six; clearly a problem with WIP limits. Discussion with Inbar to follow. Congrats Inbar and Ronit!).

That’s somewhat besides the point, so to the point, the latest BP is provided below.

SAFE LSE Big Picture  version 50.

SAFE LSE Big Picture version 50.

At this time, we have about half of the articles in some state of doneness. Even then, we are doing some refactoring and integrating a new example, so progress is not what we anticipated, (but quality has yet to suffer). We’ll have a preview site available on a limited basis sometime towards the end of this month.

The second pic (below) is just a teaser for the “Baja 100 Amusement Park systems example we will be using to explain a number of key concepts in LSE. We’ll also use that in the course exercises (Applied Lean Systems Engineering with SAFe LSE)  for the upcoming 3 day course.

LSE Project

Safe LSE Amusement Park Ride concept drawing

 

if you are an early adopter and want to experience the first version of the course, encourage us, bang on us a bit, whatever, and perhaps influence the direction of the course, its pedagogy, and the framework itself, please register here.

See you in April or sometime thereafter.

 

Categories: Blogs

Agile Middle East, Dubai, United Arab Emirates, 12 April 2015

Scrum Expert - Mon, 01/12/2015 - 18:40
Agile Middle East is a one-day conference that proposes keynotes, presentations from Agile experts and interactive workshops. In the agenda of the Agile Middle East you can find speakers like Richard Knaster (Thought Leader of Scaled Agile), Tony Grout (Skype Head of Agile Transformation), Andrew Hiles (Monitise, Head of Agile). Web site: http://agileme2015.meagile.com/ Location for the Agile Middle East conference: Hilton Dubai Jumerah Resort, Dubai, UAE
Categories: Communities

3 Requirements for Creating a Culture of Leadership & Innovation

Agile For All - Bob Hartman - Mon, 01/12/2015 - 17:15
Innovation begins with the heart... the heart of leadership

Innovation begins with the heart… a heart of leadership

The Hay Group, a global management consulting firm, released their findings that identify which organizations have the best leadership practices and what we can learn from them.

According to Hay Group’s study, the Best Companies for Leadership create workplace environments and processes that enable innovation to thrive.

In fact, all of the Top 20 companies reported that their leaders regularly celebrate innovation, compared to just 49 percent of other companies.

But you knew that already right? The most fascinating discovery, though, is how this innovation is brought to light and attention and the management and flow of idea generation. You see, 90 percent of the Top 20 companies reported that if individuals have an excellent idea, they can bypass the chain of command without the threat of negative consequences, compared to only 63 percent of other companies.

Bypassing the “chain” of command without “negative” consequences is huge – does this cultural dynamic exist in your organization? Or do you face significant tension, roadblocks, or even discouragement when bringing attention to newer ideas?

‘The Best Companies for Leadership recognize innovation is key to their future growth and ability to survive in a fiercely competitive global market,’ said Rick Lash, director in Hay Group’s Leadership and Talent practice and co-leader of the Best Companies for Leadership Study.

‘Many companies prize innovation, but the Best Companies for Leadership approach it in a disciplined way by building agile organizations, promoting collaboration, celebrating successes, learning from setbacks and fostering a culture that encourages a passion for innovation throughout the organization.’

The Hay Group polled 7,000 people in more than 2,300 companies worldwide. Respondents rated their own companies and were asked to nominate three other companies they most admire for leadership.

Each of the companies shared four common leadership traits: the company enables organizational agility, broadens perspective, focus on collaboration, and leadership drives innovation.

Among some of the more interesting survey findings were: 100 % of the best companies let all employees behave like leaders. Only 54% of peers do likewise; 90% of best companies let employees bypass the chain of command with an excellent idea; problems are opportunities, 95% of best companies think this way; collaboration is mandatory.

100% of the best companies take action when a leader is not collaborating; 95% of senior leaders take time to actively develop others. Only 48% of leaders at peer companies do this; and 95% of best companies reward leaders based on their ability to build excellent peer relationships.

 Other major findings from Hay Group’s Best Companies for Leadership Study include: Companies are better positioned for talent now and in the future  Top 20  All Other Companies  Leaders create a work climate that motivates employees to do their best 100 percent 61 percent My organization actively manages a pool of successors for mission-critical roles 100 percent 60 percent There are a sufficient number of qualified internal candidates who are ready to assume open leadership positions 100 percent 44 percent Organizations are structured for speed and agility  Top 20  All Other Companies  My company has an organizational structure that favors quick communications paths 85 percent 55 percent Roles have been designed to allow for flexibility to respond to immediate projects 90 percent 65 percent Leaders at the frontline have all the decision-making authority needed to respond to changing market conditions 75 percent 49 percent Leaders set the context for smart innovation  Top 20  All Other Companies  My company runs unprofitable projects to try new things 94 percent 49 percent Employees spend much time discussing customers’ future needs 90 percent 47 percent Employees are encouraged to learn in areas outside of their expertise 90 percent 48 percent Organizations seek and value broad perspectives  Top 20  All Other Companies  To solve problems, leaders gather points of view from multiple perspectives 100 percent 66 percent My company has a balanced mix of local and international talent in senior leadership positions 95 percent 51 percent My company recruits cultural minorities 85 percent 39 percent Leaders encourage collaboration and reward it accordingly  Top 20  All Other Companies  My organization takes clear action when a leader is not collaborating 100 percent 59 percent My company evaluates and rewards leaders based on their ability to build excellent relationships with their peers 95 percent 46 percent Our incentive plans put significant weight on team-based measures 84 percent 56 percent

As a result there appears to be three consistent patterns that have been created that promote significant innovation and a culture that helps the organization thrive:

1. A place of Empowerment.

As the Hay Group survey reveals, the best companies are those that let employees behave like leaders. What a novel concept. When team members are empowered to behave as leaders they will not disappoint. Given the opportunity, empowered employees will work hard to meet and exceed expectations.

2. A place of Possibilities.

Within this culture of leadership and empowerment is a place of unlimited possibilities. While many companies choose to play it safe; consider this finding from the Hay Group survey – 94% of best companies are prepared to run unprofitable projects to try new things.

3. A place of Vision.

Winfred Newman said, “Vision is the world’s most desperate need. There are no hopeless situations, only people who think hopelessly.” He is right. The single greatest drawback to the advancement of your organization is a lack of vision. Until the vision is known, don’t expect a culture of leadership to thrive much less exist.

Your challenge, as a leader, is to make sure you create the right culture that will persist through the good times and bad, through the times of significant innovation and through the times where you don’t hear much new at all.

Make sure you have the right tools in place so that innovation and cultural growth can occur. We’d love to help.

The post 3 Requirements for Creating a Culture of Leadership & Innovation appeared first on Agile For All.

Categories: Blogs

Does Agile Work Because We are Optimistic?

Johanna Rothman - Mon, 01/12/2015 - 15:50

I read the Business Week opening remarks, How Optimism Strengthens Economies.  See this quote at the end:

the group of people who turn out to be most accurate about predicting how long it will take to complete tasks—and how likely they are to succeed—are the clinically depressed. Optimists underestimate how difficult it will be to succeed. But that self-deception is precisely what makes them willing to take more risks and invest in a better future, while the pessimists slouch toward self-fulfilling failure. 

Pessimistic people are more accurate with their estimation. Optimists underestimate. Their optimism allows them to take more risks and innovate. Which kind of person are you? (I’m both, in different circumstances.)

That got me thinking about why agile works.

Agile and lean (I’m using agile as shorthand for both) help us make progress in small chunks. That creates hope and optimism in the project team. When the project team demos or releases to other people, they trust the team and a become hopeful and optimistic.

We know from The Progress Principle: Using Small Wins to Ignite Joy, Engagement, and Creativity at Work that the more we make progress with small wins, the better we feel and the more likely we are to make more progress. That leads to hope and optimism.

Is this why agile works? Because we can make progress daily?

It’s not the only reason. We also need feedback. When we provide demos to other people, as often as possible, we build trust. With trust comes the possibility of better connection and feedback.

We get feature-itis because we’re no longer in requirements hell. Other people can see that a project team can deliver. That leads to optimism and hope in the organization. (I’m differentiating the two, because they are different. See my review of Seligman’s book.) With hope, people can rise to many occasions. Without hope? I bet you’ve been there on a project. It isn’t pretty.

Agile is not for everyone. Agile approaches? Yes. Completing small chunks of work and showing it to other people? You can do that with deliverable-based planning, building incrementally, and iterative approaches to replanning. If you want a name for that approach, it’s called staged delivery or design to schedule.

If you’re doing agile well, you’re delivering new small features into the code base every day or every other day. That helps you feel as if you’re making progress. When you feel as if you’re making progress, you can be more optimistic or hopeful. That helps you see new possibilities.

I would rather work in a hopeful way, making progress on a project, than feel as if I’m dragging. What about you?

So, agile might increase optimism, which allows us to make more progress and innovate. Agile done well brings joy to our work.

People are always asking my why agile works, or to prove it works. I can’t prove anything.

I have said that in my experience, when people work in an agile way, they are more productive and more effective. Now I wonder if this is because they are optimistic and hopeful about their work.

Categories: Blogs

Interchangeable Project Lenses Can Reveal the Unseen

George Dinwiddie’s blog - Mon, 01/12/2015 - 15:26

If you look at things from the same point of view all the time, you’ll tend to see the same things, and overlook the same things. I discuss on ProjectManagement.com how to vary your view to get a better overall picture.

Categories: Blogs

Special Agile Events Coming to Dallas in March 2015

DFW Scrum User Group - Mon, 01/12/2015 - 15:24
We’ve highlighted some upcoming agile events during our monthly meetups, and I know it can be difficult to remember the details later (especially the URLs).  Information about two special events coming to Dallas in March 2015 is below: The first event is … Continue reading →
Categories: Communities

New Features for Speed, Visibility, and Scale

Rally Agile Blog - Mon, 01/12/2015 - 15:00

Scaling Agile is all about coordinating work across development teams and aligning that work to your top business priorities—so you can deliver value to customers. If you’ve got Agile programs spanning multiple development teams across multiple sites, it’s imperative that you have tools to help you manage the complexities of working collaboratively at scale. Over the past few months, Rally has introduced several new features to help you do just that.  

Milestones

In November Rally launched milestones, which allow you to connect your most important development work to the critical deadlines, events, or releases your business needs to hit. With milestones you can link stories, features, or whole releases to a particular date: a market event, a trade show, or an important code deployment. Since the value of whatever you build doesn’t count until it reaches the customer, being able to plan and track your work against key events like this helps you steer your development to critical business goals.

Portfolio Item Dependencies

In December Rally introduced portfolio item dependencies, giving you the ability to plan for and manage critical dependencies among your features and releases.  

To build and execute on realistic release plans, you’ve got to account for feature-level dependencies across development teams—work that must get done before a feature can be completed. For example, you might have specialized teams building pivotal, individual components for a feature; or you might have several features that all contribute to the marketability or readiness of a major release. Now you can create, assign, view, edit, or delete portfolio item dependency relationships for any portfolio item from the new portfolio item editable detail page (in beta.)

The ability to see dependencies is especially powerful during collaborative release planning events (for example, big room planning) because it encourages cross-team conversations that mitigate risks, foster commitment, and yield a successful plan for completing development work.

During development, the ability to visualize both story-level and portfolio-level dependencies also helps teams understand when work they depend on is ready (predecessors) or when their work is needed (successors.) This allows them to plan their iterations more effectively, and fosters collaboration between teams so they can resolve bottlenecks in a timely way.  

Hierarchical Portfolio Items Page

Rally also has introduced a new hierarchical portfolio items page (currently in beta) that shows you how stories connect to their parent features, and how these features in turn connect to the key business initiatives to which they contribute value—all in one hierarchical view.  

This rolled-up, simplified view has benefits to everyone involved in a scaled Agile program. Here's how:

  • Agile development teams understand the business reasons behind their user stories by seeing how they connect to features, initiatives, and higher-level portfolio investments. This helps teams feel like they have skin in the game for delivering value to the business, and helps them minimize waste by keeping their focus and resources aligned.

  • PMOs and engineering leaders get an aggregated, high-level status view from which they can quickly identify problem areas, drill down to see the features that are causing bottlenecks, and steer to a successful resolution.

  • PMOs and business leaders can assess the level of investment in key portfolio priorities—and actively adjust priorities and resources for the most profitable direction—by seeing full traceability from the portfolio level to the development task level.

New Task Board

We’ve given the task board in Rally an entirely new look and powerful new features to help you plan and manage your daily work faster and easier. This new task board view lets you add new tasks and user stories, view and edit fields directly in tasks, and use advanced filtering capabilties to view only the specific tasks you care about.

Custom Board

The App Catalog now includes a custom board that lets you visualize your data the way you want it. Do you want to see a feature Kanban organized by initiative swimlanes, or features grouped by milestones? Do you want to create Kanban boards based on custom fields? Rally’s new custom board is easily configurable so you can build exactly what you need. Just select the work item type you'd like to see, specify the information type to be displayed in the board’s rows and columns (from fields like milestone, owner, state, priority, etc..,) and select which fields to display on the board. From there, you can leverage your custom view boards to quickly edit values.

Eclipse with SSO

More and more companies are adopting single sign on, or SSO, to ensure secure access to all the key software systems they use while simplifying login procedures for their users. Along with Rally’s Visual Studio IDE plugin, our popular Eclipse IDE plugin now supports SSO. These plugins are used by developers to view or update stories, tasks, and defects without having to leave the IDE, providing context for their work and simplifying their workflow. Companies that require SSO can now take advantage of the integration these IDE plugins provide without the administrative overhead of managing a whitelist.

We look forward to hearing how these new Rally features help you plan, track, and deliver on your Agile programs! Get help with using these features at the Rally Help site, or contact your Technical Account Manager (TAM) to learn more.

Steve Wolfe
Categories: Companies

SUGSA Johannesburg Committee Nominations 2015

Scrum User Group of South Africa - Mon, 01/12/2015 - 11:05
Happy New Year to everyone!! 2014 was a very successful year for the JHB committee and the community. We would like to thank the 2014 committee for all their hard work. Every year we hold elections for a new committee, and we are thrilled to see a few new faces that have put their names forward. Voting for […]
Categories: Communities

Welcome to the High-Performance Teams Game

Notes from a Tool User - Mark Levison - Mon, 01/12/2015 - 09:50


High-performance Team Game for Scrum/AgileYour team is working on the World’s Smallest Online Bookstore, a site that provides the best results (just a few) for every search, not every result on earth. We’re a vulture capital funded company, so if we don’t deliver, our funding will be cut.

So begins the opening of the High-Performance Teams Game.

My goal is to help you see the effects of choices/tradeoffs on productivity and team cohesion. While some of the benefits of Agile happen at the individual level, there are many things that affect the relationships between team members, and therefore the overall cohesion and productivity of the team.

The game is played by a team of 5-9 people, in a series of  5-6 rounds. During each round there is a little bit of teamwork, a little bit of discussion of the science, and some game play. Each round represents 6 weeks, or three 2-week sprints. In each round you have budget for the amount of work/stuff you can do based on your team’s capacity. Some of that budget must be spent on delivering features, otherwise the business will threaten to let you go. Some of it should be spent on growing the team and their engineering skills, otherwise you don’t get more budget capacity.

Some of the leading research [1][2] suggests that a key requirement for high performance teams is Cohesion. Cohesion is a measure of the strengths of the relationships between individual team members.

In this session we will use this research to discover:

·      Simple communication patterns we can monitor to spot the health of the team.

·      Simple tools we can use to measure and track those patterns.

·      What effect does the location of the watercooler have? What effect do lunch tables have?

·      Can cohesive teams get you into trouble?

·      The importance of dissent and diversity within teams.

·      Bonuses – the negative effects of individual bonuses are well understood by the Agile community. However, we’re left with the question: Are there good bonuses?

Downloads Available Game Material (Dropbox folder):

 

Facilitators Material:

Magic and Science of Teams Game Edition from Mark Levison

 

In addition to the game material, I’ve written a paper on the “5 Steps Towards High-Performing Teams”.

Enjoy playing with your team.
Creative Commons License
High Performance Teams Game by Mark Levison – Agile Pain Relief Consulting is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

 

 

Feedback from GOAT (Gatineau Ottawa Agile Tour 2015): During game play at the conference, only the facilitator knew the benefit/effects of each action while the game progressed. As a result, in the 90 minute session some teams had a difficult time keeping track of the calculations. Future editions will reveal all the calculation details on paper to the attendees in the round after they’ve played.


[1] Sandy Pentland – The New Science of Building Great Teams
[2] Ben Waber – People Analytics

 

Categories: Blogs

Knowledge Sharing


SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.