Skip to content

Feed aggregator

New blog entry at

NetObjectives - Wed, 01/21/2015 - 13:33
Scott has added an entry called TDD and Defects to the Sustainable Test-Driven Development blog site, sponsored by Net Objectives. Author: Scott Bain

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Looking back on 2014

AvailAgility - Karl Scotland - Wed, 01/21/2015 - 13:24

This is a little later than I would have liked, but 2015 seems to have had a busy start! As I look back on last year, the main thing that stands out for me was my decision to go solo. As a result, the second half of the year was an interesting learning curve for me, and as I look forward to 2015, I’m please with the way events have unfolded, and excited by future possibilities. In particular, I’ve been able to focus more time on Kanban Thinking, including put together the downloadable Kanban Canvas, and writing more about how I use it.

On the topic of writing, you can read the blog’s 2014 annual report for the full statistics. The highlights for me were the fact that I had my busiest day, and I managed 23 posts – a significant increase from 2013. I hope I can maintain, and even continue to improve that number. Also interesting is that the top 3 posts remain the same; Kanban, Flow and Cadence“,What is Cadence? and Fidelity – The Lost Dimension of the Iron Triangle. Its nice to see Running the Ball Flow Game come in at number 4 – I love playing that game in workshops and it always seems to generate good discussion and learning. Finally, Making an Impact with Kanban Thinking is at number 5, and given that this is a recent post, I hope this bodes well for the future of Kanban Thinking in general.

The other big passion of mine in 2014 was taking up running, which I mentioned a when I posted on Estimates as Sensors. According to MapMyRun, I did a total of 177 runs, with an average run of 5.11 miles (giving a total of 904.5 miles), and a longest run of 17 miles. My average pace was 9:06 min/mile and my fastest pace was 4:31 min/mile.

For posterity, here’s my PB’s for the 2014

I’m currently training for the Brighton Marathon (watch this space for a call for sponsorship) so I’m also expecting those number to go up (or down for pace!). As part of my running addiction, I’ve become involve in my local parkrun community – something I gave a lightning talk about at LKUK14.

Thanks you for reading this blog, and for the continued support. I look forward to more of the same in 2015, and hope I get to meet many of you in person. Please let me know if you’d like me to work with you, or just say “Hi” if you see me at a conference or event.

Categories: Blogs

fighting temptation and building good habits

Derick Bailey - new ThoughtStream - Wed, 01/21/2015 - 13:00

A reader recently asked me a question about habits, and building good ones:

What is the best way to form good habits? You see all these books: Miracle Morning, Getting Things Done, Superhuman by Habit, Pomodoro Technique, etc. They all provide ways to better manage your time, so you have time for side projects, etc. But most of them don’t really say what to do when you are tired, feel like hitting the snooze button rather than getting up, or feel like checking twitter rather than banging out the 20 unit tests on your plate. What do you do to stay focused and form good habits?

As I was thinking about the questions and thoughts about what I wanted to say were running through my head, I realized that most of what I wanted to say were things that my friend John Sonmez had been talking about recently. John’s a fountain of knowledge, when it comes to getting things done, building habits and generally making yourself a better person, not just a better developer. So, rather than me trying to re-hash the things that John says so well, I asked him to respond to the questions directly. Fortunately for me, and you, he did!

Here, as a guest post to my newsletter and archive, is John Sonmez, answering the question of how to build good habits.

I don’t know if you know it or not, but you’ve basically just asked the question “what is the secret to success?” because habits—and more specifically executing on them when you don’t feel like it—is exactly that.

If I could take success and put it in a bottle and drink it, it would taste like consistency and sweat. (In case you are wondering “consistency” tastes a bit like slightly soured milk, and sweat… well, it’s salty.)

Every single successful person I know has figured out some way to bottle this substance and to drink healthy servings of it, just about every day.

But, of course this is a lot easier said than done—otherwise we’d all be super successful.

So, how do you actually become consistent?

How do you actually develop habits?

Especially when the passion has died down and you just aren’t feeling motivated?

Unfortunately, there is no easy answer to these questions.

I can’t handle you that bottle of sour milk and sweat for you to drink. It’s up to all of us to brew up our own batch.


Brewing up a batch of “success” juice

It all starts with the proper mindset.

As lazy human beings, we tend to be pretty short-sighted.

My wife handed me two Cadbury Creme Eggs that she picked up when she went to the store and they are sitting there on my desk, staring at me, trying to prevent my mind from thinking about anything else.

I have to actively fight and resist the urge to eat them, because I know that eating chocolate eggs, when I am supposed to be working and when they aren’t on my planned diet, is going to be counter-productive to my long term goals.

But, I am resisting them. I am sitting here typing this email, because I’ve figured out—at least in some way—to shift my thinking from the short-term to the long-term.

If you want to get out of bed instead of hitting the snooze button, you have to think about more than just today. You have to think about how making that decision 100 or 1,000 times will affect your life. That is what thinking in the long-term is about.

If you want to write those unit tests and get some real work done. You’ve got to think about how choosing to work instead of goofing off is going to play out over the course of the next 5 years.

It’s not easy to think this way, so most people don’t even try.

Most people just make the short-term decision that feels good.

They plop down in front of the TV, instead of working on their side-project.

They stuff their face full of junk, instead of carefully planning their meals and losing the 10—or 50—pounds they’ve been trying to lose for the last 5 years.


They are the same kind of people who always start out with good intentions.

We’ve all been that kind of person at some time in our lives—perhaps you are now. (I know I still am from time-to-time.)

But, we have to fight it.

We have to see something bigger on the horizon.

We have to realize that when we give up a battle with temptation, laziness or procrastination, we aren’t just making a single decision, we are setting a course. A course that will eventually run our ship aground.

Only by changing your mindset to realize these things—to thing big; long term—can you ever hope to build and execute on good habits.

Most people know exactly what they need to do to achieve their goals in life.

Fat people know they need to stop eating so much and exercise more.

Broke people know they need to stop spending so much.

Lazy people know they need to stop procrastinating all the time.

But, do they do it?


Will you do it?

It’s up to you.

The drink isn’t very tasty and it has a hell of a bite, but if you mix up a batch and start chugging it, you’ll do what 99% people are incapable of.

And when you do, productivity tricks aside, you are going to see results.

That’s all I have time for to include in this email, but I have a whole section devoted to productivity in my book “Soft Skills: The Software Developer’s Life Manual.”

You can also find a chapter that deals specifically with how to be get things done when you don’t feel motivated called “Burnout? I’ve got the cure.

– John Sonmez

Categories: Blogs

Scrum in der Hardware – eine Zwischenbilanz

Scrum 4 You - Wed, 01/21/2015 - 08:46

Als Takeuchi und Nonaka 1986 den Artikel “The New New Product Development Game” veröffentlichten, fiel das Wort “Scrum” zum ersten Mal im Kontext der Produktentwicklung. Dort ging es nicht um Softwareapplikationen, sondern um Kopierer, Fotokameras und PCs. Dennoch stand die Blütezeit von Scrum ganz im Zeichen der Softwareentwicklung: Das Rahmenwerk, das wir heute kennen, entstand in den 1990er und frühen 2000er-Jahren.

Allmählich wird Scrum für die Hardwareentwicklung wieder entdeckt. Das ist kein Zufall: Die Entwickler von Hardwareprodukten stehen heute vor ähnlichen Herausforderungen wie die Softwareentwicklung Anfang der 1990er Jahre. Unternehmen in der Medizin- oder Messtechnik, die vor einem Jahrzehnt mit einer handvoll innovativer Produkte die Marktführerschaft erobert haben, müssen wieder einmal vorangehen. Doch dieses Mal sind die Vorzeichen andere: Ihre Produkte verkaufen sich mittlerweile in der ganzen Welt und die Konkurrenz ist in der Lage, die Produkte aus dem Katalog in kurzer Zeit nachzubauen und preislich zu unterbieten. Um die Marktführerschaft zu erhalten, müssen Unternehmen am Ball bleiben.

Am Ball zu bleiben wird umso schwieriger, je erfolgreicher das Unternehmen ist. Denn Wachstum bedeutet häufig auch, dass selbständig agierende, kleine Teams einer übegreifenden Abteilungs- und Projektstruktur weichen müssen. Wie können innovative und zuverlässige Produkte entstehen, wenn ganze Entwicklungsabteilungen vor sich hin arbeiten, die dann auch noch mit QA, Fertigung, Einkauf, Produktmanagement und Vertrieb in Einklang zu bringen sind?

Scrum bietet mit seinem Augenmerk auf selbstorganisierte Einheiten, in denen das Wissen der Abteilungen im Mikrokosmos eines Teams gebunden ist, eine erfrischende Alternative zu herkömmlichen Produktentstehungsprozessen. Wie aber sehen die bisherigen Erfahrungen mit Scrum in der Hardwareentwicklung aus? Es ist Zeit, eine Zwischenbilanz zu ziehen.

Eine Mannschaft aufstellen, die alle Positionen beherrscht

Für die erfolgreiche Lieferung eines Hardwareprodukts braucht es nicht nur Spezialisten für Software, Hardware und Konstruktion. Zulieferer, Fertigung und QA können entscheidende Beiträge leisten, wenn es um die richtige Auswahl von Bauteilen oder um geeignete Produktionsverfahren geht. In Scrum haben wir den Vorteil, dass wir jeden dieser Spezialisten völlig unbürokratisch in jene Sprints mit einbinden können, in denen ihr Wissen gefragt ist. Diese sind dann z.B. Teil des 15-minütigen Daily Scrums und können darin selber Aufgaben übernehmen. Je früher sie eingebunden werden, desto überflüssiger werden die üblichen zeit- und kostenintensiven “Nachbesserungsrunden” vor (und häufig sogar nach) dem Produkt-Launch.

Was bringt die Software ohne das Gehäuse?

Gerade in der Hardwareentwicklung können leicht “Paralleluniversen” entstehen. Der Konstrukteur baut sein Gehäuse, der Hardware-Entwickler seine Platine. Erst spät fällt auf, dass beides nicht so richtig zusammenpasst, weil z.B. die Bohrungen für die Befestigungen den Bestückungsraum für die Platine einschränken. Oder weil die vorgesehene Lichtleiterkonstruktion Dichtigkeitsprobleme beim Ausschäumen hervorrufen könnte. Wenn das Wissen um diese Abhängigkeiten im Team vorhanden ist, können die Inkremente auf Komponenten-Ebene (Gehäuse, Platine) zu einem Inkrement auf Produkt-Ebene zusammengeführt werden. Das Team stellt dann im Sprint Review einen Stand des Produkts vor, der bereits aus verschiedenen Perspektiven (Konstrukteur, HW-Entwickler, Fertiger) verifiziert worden ist.

Die richtige Lösung für das richtige Problem

Wenige Unternehmen sind es gewohnt, Kunden und User zu ihren Sprint Reviews einzuladen. Am Ende entstehen so Produkte, die ein Problem lösen, das der Kunde so gar nicht hat. Dabei kann gerade in der Hardwareentwicklung mit einfach Mitteln (3D-Drucker, virtuelle Modellierung) ein sehr konkretes Bild des künftigen Produktes vermittelt werden. Dafür braucht es einen Product Owner, der direkte Anbindung an den Markt hat (und nicht nur auf die Anforderungen des Vetriebs angewiesen ist), den Kunden mit einer eigenen Vision führen kann (anstatt ihn zu fragen, was er denn haben möchte) und in die Stärken seines Entwicklungsteams vertrauen kann. So können die Reviews genutzt werden, um das Produkt durch Kunde und User validieren zu lassen und so möglichst früh Weichenstellungen in der Entwicklung durchzuführen.

Über den Sprint hinausschauen

In der Softwareentwicklung messen wir den Durchsatz an entwickelten Funktionalitäten pro Sprint, um die Geschwindigkeit des Teams zu bestimmen. In der Hardwareentwicklung müssen wir anders vorgehen, da die Laufzeiten bis zur Fertigstellung einer Funktionalität länger sind. So sind mehrere Entwicklungsschritte (z.B. Platzstudie, Stromlaufplan, Layout, PCB) erforderlich, bis eine Funktionalität (z.B. das Auslesen von RFID-Tags) fertig ist. Deshalb bauen wir das Product Backlog auf zwei Ebenen auf:

  1. Auf der Feature-Ebene sind die Funktionen des Produkts aus Benutzersicht mit ihren Rahmenbedingungen beschrieben (z.B. das Auslesen und Beschreiben von Datenträgern mit einer bestimmten Geschwindigkeit und Leseabstand).
  2. Auf der System-Ebene sind die Entwicklungsschritte innerhalb der verschiedenen Disziplinen (Konstruktion, Hardware, Software) beschrieben, die zum Erreichen der gewünschten Funktionalität erforderlich sind. Wir ermitteln die Geschwindigkeit auf dieser zweiten Ebenen (wie viele Entwicklungsschritte schafft das Team pro Sprint), um die Dauer bis zum Erreichen der ersten Ebene (fertig gestellte Funktionalitäten) zu ermitteln. Hierbei ist die Berücksichtigung von harten Abhängigkeiten (wann läuft die Entwicklung leer, weil sie z.B. auf Lieferungen der Software angewiesen ist?) wichtig, um eine rechtzeitige Einplanung in die Sprints zu ermöglichen.

Scrum ist seinerzeit angetreten, um Unternehmen, die sich in Entwicklungsphasen und Abteilungsdenken verzettelt hatten, wieder lieferfähig zu machen. Mit Scrum haben wir ein vergleichweise leichtes Regelwerk, das durch kurze Iterationen und interdisziplinäre Teams den Augenmerk auf eine zuverlässige Integration des Produkts bei einer klaren Ausrichtung am Markt legt. Nirgendwo ist dieser Bedarf dafür aktuell größer als in der Hardwareentwicklung.

Whitepaper Scrum in der Hardwareentwicklung

Tipp: Am 10.2.2015 diskutieren wir von 16 bis 17 Uhr in einem Webinar über Scrum in der Hardwareentwicklung. Unsere Gäste sind Claus Höhn, Entwicklungsleiter der Business Unit Identification bei Balluff GmbH und Christoph Wehe, Product Owner bei Thermo Fisher Scientific Inc. Alle Infos dazu gibt es hier

Categories: Blogs

January Newsletter: Future of Lean, DeGrandis Joins LeanKit, New Help Center, and More

Here’s the January 2015 edition of the LeanKit monthly newsletter. Make sure you catch the next issue in your inbox and subscribe today. What is the Future of Lean? Dan Jones and Jim Womack, founding fathers of the Lean movement, discuss the current state, evolution, and future of Lean thinking. Hear their thoughts about the […]

The post January Newsletter: Future of Lean, DeGrandis Joins LeanKit, New Help Center, and More appeared first on Blog | LeanKit.

Categories: Companies

Roadmapping and Mentoring

Agile Artisans - Wed, 01/21/2015 - 02:00

A coaching model that I've found very effective is something I call roadmapping and mentoring. In a traditional coaching engagement, the coach comes alongside the team and works onsite for some period of time. This is a very effective way to work and teach, but also requires a substantial budget commitment. It also needs a dedicated block of time from the coach. Lining up client needs with coach?s availability is often challenging, and there?re usually problems that are discovered after the engagement is complete and the coach is at a different client site. These problems are often insurmountable for the small or medium software shop.

Roadmapping puts a coach back in reach for most teams. The coach comes onsite for only few days, and that drastically reduces the cost. I meet with both the teams and the leadership. What pain points triggered this invitation? We try to identify what the existing pain is, but we also look for pain that the team has come to accept as normal. What hidden pain poi

Categories: Companies

DevOps Evangelist Dominica DeGrandis Joins LeanKit

We’re excited that Dominica DeGrandis has joined LeanKit as our Director of Training and Coaching. Dominica is well known for her work with IT and Operations teams as a Kanban for DevOps trainer and coach. As a highly recognized international speaker, she’s often on the road, appearing at events focused on Lean, Kanban, Agile, and DevOps. […]

The post DevOps Evangelist Dominica DeGrandis Joins LeanKit appeared first on Blog | LeanKit.

Categories: Companies

Kick Off 2015 with New Features

Over the past several weeks, we’ve released many features including enhancements to the mobile apps, calendar view, and collaboration tools. Here’s a quick rundown so you know what to try the next time you’re in LeanKit. Using My LeanKit Mobile Apps — Offline Your new ideas and to-do items won’t get lost when you’re unable to connect to […]

The post Kick Off 2015 with New Features appeared first on Blog | LeanKit.

Categories: Companies

Backlog Selection By Cost of Delay

Scrum Expert - Tue, 01/20/2015 - 19:58
Managing the product backlog and prioritizing the user stories if one of the main responsibilities of the product owners in Scrum. In this blog post, Andy Carmichael explains how to assess the priority of product backlog items using the cost of delay. The cost of Delay is the cost to bear as a result of delay in investment. Andy Carmichael bases his analysis on David Anderson’s Kanban book that proposes four archetypes to categorize the costs of delay, plotting on a chart the impact (opportunity cost) against the time of release. ...
Categories: Communities

Integrating MediatR with Web API

Jimmy Bogard - Tue, 01/20/2015 - 19:25

One of the design goals I had in mind with MediatR was to limit the 3rd party dependencies (and work) needed to integrate MediatR. To do so, I only take a dependency on CommonServiceLocator. In MediatR, I need to resolve instances of request/notification handlers. Rather than build my own factory class that others would need to implement, I lean on CSL to define this interface:

public interface IServiceLocator : IServiceProvider
    object GetInstance(Type serviceType);
    object GetInstance(Type serviceType, string key);
    IEnumerable<object> GetAllInstances(Type serviceType);
    TService GetInstance<TService>();
    TService GetInstance<TService>(string key);
    IEnumerable<TService> GetAllInstances<TService>();

But that wasn’t quite enough. I also wanted to support child/nested containers, which meant I didn’t want a single instance of the IServiceLocator. Typically, when you want a component’s lifetime decided by a consumer, you depend on Func<Foo>. It turns out though that CSL already defines a delegate to provide a service locator, aptly named ServiceLocatorProvider:

public delegate IServiceLocator ServiceLocatorProvider();

In resolving handlers, I execute the delegate to get an instance of an IServiceLocatorProvider and off we go. I much prefer this approach than defining my own yet-another-factory-interface for people to implement. Just not worth it. As a consumer, you will need to supply this delegate to the mediator.

I’ll show an example using StructureMap. The first thing I do is add a NuGet dependency to the Web API IoC shim for StructureMap:

Install-Package StructureMap.WebApi2

This will also bring in the CommonServiceLocator dependency and some files to shim with Web API:


I have the basic building blocks for what I need in order to have a Web API project using StructureMap. The next piece is to configure the DefaultRegistry to include handlers in scanning:

public DefaultRegistry() {
        scan => {
			scan.With(new ControllerConvention());

This is pretty much the same code you’d find in any of the samples in the MediatR project. The final piece is to hook up the dependency resolver delegate, ServiceLocatorProvider. Since most/all containers have implementations of the IServiceLocator, it’s really about finding the place where the underlying code creates one of these IServiceLocator implementations and supplies it to the infrastructure. In my case, there’s the Web API IDependencyResolver implementation:

public IDependencyScope BeginScope()
    IContainer child = this.Container.GetNestedContainer();
    return new StructureMapWebApiDependencyResolver(child);

I modify this to use the current nested container and attach the resolver to this:

public IDependencyScope BeginScope()
    var resolver = new StructureMapWebApiDependencyResolver(CurrentNestedContainer);

    ServiceLocatorProvider provider = () => resolver;

    CurrentNestedContainer.Configure(cfg => cfg.For<ServiceLocatorProvider>().Use(provider));
    return resolver;

This is also the location where I’ll attach per-request dependencies (NHibernate, EF etc.). Finally, I can use a mediator in a controller:

public class ValuesController : ApiController
    private readonly IMediator _mediator;

    public ValuesController(IMediator mediator)
        _mediator = mediator;

    // GET api/values
    public IEnumerable<string> Get()
        var result = _mediator.Send(new Ping());

        return new string[] { result.Message };

That’s pretty much it. How you need to configure the mediator in your application might be different, but the gist of the means is to configure the ServiceLocatorProvider delegate dependency to return the “thing that the framework uses for IServiceLocator”. What that is depends on your context, and unfortunately changes based on every framework out there.

In my example above, I’m preferring to configure the IServiceLocator instance to be the same instance as the IDependencyScope instance, so that any handler instantiated is from the same composition root/nested container as whatever instantiated my controller.

See, containers are easy, right?


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

Categories: Blogs

News update 2015/01 – Scrum Coaching Retreat Cape Town - Peter Hundermark - Tue, 01/20/2015 - 15:29

Scrum Coaching Retreat Cape TownYou may be considering attending the upcoming Scrum Coaching Retreat (SCR) to be held in Franschhoek, near Cape Town on 09-11 February 2015. And you may be wondering what the value will be to you. You may also need to find a convincing argument for your boss to sign off on the registration fee and, perhaps, travel costs from Jhb or elsewhere.

Well in this month’s blog post, Peter Hundermark shares his personal experiences of past Scrum Coaching Retreats in Colorado and London. Discover what he learnt and what to expect from South Africa’s inaugural event! Read more HERE.

CLICK FOR EVENT DETAILS Upcoming Courses Certified Scrum Master (CPT)
26-27 Jan 2015
Steenberg Hotel, Cape Town


Certified Scrum Master (JHB)
03-04 Feb 2015
FNB Conference & Learning Centre, Sandton


Certified Scrum Product Owner (CPT)
23-24 Feb 2015
Steenberg Hotel, Cape Town


Certified Scrum Master (JHB)
10-11 Mar 2015
FNB Conference & Learning Centre, Sandton


Course schedule and Book Online

The post News update 2015/01 – Scrum Coaching Retreat Cape Town appeared first on ScrumSense.

Categories: Blogs

Viktor Frankl’s Meaning Triangle for Organizations

Agile For All - Bob Hartman - Tue, 01/20/2015 - 15:15

Viktor_Frankl2Viktor Frankl was an incredible human being, having survived the Holocaust and establishing logotherapy, a type of psychotherapy. His book, Man’s Search for Meaning, details his development of his theory around meaning and suffering.

And he was a student of suffering as he and his fellow prisoners walked through horrifying conditions. What he discovered, though, was how some of his colleagues were able to not only survive but grow in the process.

His conclusion – that the most basic human motivation is the will to meaning, and as Nietzsche put it,

He who has a why to live for can bear almost any how.

Frankl outlines further what he calls the “Meaning Triangle” as a way of processing the growth that some would face in seemingly hopeless circumstance:

  1. Creativity – Giving something to the world through self-expression and using our talents in various ways.
  2. Experiencing – Receiving from the world through nature, culture, relationships, and interactions with others and with our environment.
  3. Change of Attitude – Even if we can’t change a situation or circumstance we can still choose our attitude toward a condition. This is often a self-transcending way of finding meaning through suffering.

viktor-frankl-meaning-triangleI have been personally inspired by Viktor Frankl’s story and his work as he has created some incredible points of connection for me as I have walked through difficult times.

His work in logotherapy has also provided many talking points for the variety of teams, organizations, and cultures that we engage with – as all teams and businesses are challenged with being responsible for their human capital (creativity) and managing it well, creating the right environment for their staff and teams to operate (experiencing), and finally providing the right tools and culture to assist in developing a positive attitude (or change of attitude) to do their best work.

How have you experienced the Meaning Triangle in your context and in your organization? What are the tools or the systems within your culture that help your team achieve greater results, individually and collectively?

Now, we wouldn’t always say (at least explicitly) that we’re “suffering” in our work daily, and obviously not to the extent of which Frankl has experienced, but we all know what it’s like to work in environments where it seems “meaning” and “purpose” are often dismissed for the tasks at hand or stepped over for the sake of surviving the “daily grind.”

What I love doing is to help organizations move back to their original purpose(s) and what made them such an exciting organization to work for and with – and help capture the reasons why they exist in the first place. This reminds the individuals and teams that there’s meaning behind the “suffering” and even greater opportunities to thrive.

The post Viktor Frankl’s Meaning Triangle for Organizations appeared first on Agile For All.

Categories: Blogs

Fantastic Team Building Activity!

Growing Agile - Tue, 01/20/2015 - 11:45

We talk a lot about the importance of creating teams in agile. People need to learn to work together towards an overall goal and share accountability rather than each person doing only their piece and not caring about the whole. It takes a long time for a new team to gel and really become a team, but there are team building activities that can help.

In December, I was lucky enough to discover a great team building activity available in Cape Town, London, Paris and Dubai! It’s called HintHunt. My team and I enjoyed it so much we went back in January to play their second room!

Team Code Monkeys cracks the Zen room at Hint Hunt.

Team Code Monkeys cracks the Zen room at Hint Hunt.

What is it?

  • Imagine a team of people (3 to 6)
  • With a strict timebox of 1 hour (let’s call it a sprint)
  • and a shared goal to achieve in that time (getting out of the room)

How do you do it?

  • You have to use problem solving skills
  • And communicate well between all the team members
  • You can even track where you are with a whiteboard

Does everyone succeed?

Actually no, that’s the part that makes it so much fun, it’s a real challenge. I don’t remember the exact stats but only about 40% of people have solved the first room, and about 10% have solved the new zen room.

Anyone else thinking this sounds exactly like Scrum?

As soon as I played I realised this is the ideal game for a Scrum team to play together. It builds teams to do exactly what they need to do to build great software, and it’s a great deal of fun. So if you live in one of the cities I’ve mentioned be sure to check it out.

Let us know if you beat our record of 1 min 59 sec remaining on the clock for the Zen room :)

Categories: Companies

The ‘Agile Playbook’

Agile Management Blog - VersionOne - Mon, 01/19/2015 - 20:51

Football players spend a lot of time studying their Playbooks. And Coaches spend a lot of time creating and updating them. These guys are serious. The stakes are high in the NFL; millions of people are watching. Their stated goal is the same each week; to win. That means they gotta work really well together and know what they’re doing.


I think the game of American football is a great example to follow as an Agile team in the corporate world. We all need some help with remembering stuff, and getting it down so we can execute on game day. Even if we’ve done it many times before, it’s easy to get forget; there’s just so much to know and remember. This is hard stuff we’re doing, and it’s in constant flux. We often find ourselves wanting someplace to go for reference, clarification, advice, dare I say… ‘best practices.’

I’ve had several clients (both large and small) ask me for something they could use to document the way they ‘do Agile.’ If they’re new to the game, often they will look to a consultant or Agile Coach to guide them or help create this information.

Enter ‘The Agile Playbook.’

So what is an ‘Agile Playbook,’ anyway?

In short, it’s a helpful guide. It can come in many forms. For now, let’s stick with the football analogy. If you’ve watched an NFL game recently, you’ve probably seen the coach holding up a play sheet, as he decides what play to call. If you (or your kid) has an XBOX or PlayStation with Madden NFL, you know it has a Playbook feature built into it. Note: this could be an interesting feature opportunity for Agile Lifecycle Management (ALM) tool providers, huh? But I digress. So, as for the Playbook itself, I think of this as the larger, over-arching deliverable.

Transferring this idea of an NFL Playbook into the world of Agile software development is natural. I’ve heard it referred to by different folks in similar ways, like ‘Agile one-stop shopping’, or an ‘Agile Coach in a Box’, or ‘How we do Agile here at Company XYZ’. I personally like the term ‘Agile Playbook’ because it’s short, simple, descriptive, and I believe it drives home the team concept nicely.

Who wants an Agile Playbook?

Can you imagine an NFL team without an organized list of plays? So why would we think it’d be any different in our Agile organizations? I remember playing pickup football and we’d draw pictures in the dirt of what we wanted to do. That was fine for a pickup game, but even my nine-year-old son’s flag football team has a playbook. So the question of ‘Who wants it?’ is an appropriate one. If we think of Mike Cohn’s user story template (As a ___, I want to ___, so I can ___), this is the ‘As a’ piece. Who are we doing this for, anyway? Is it the PMO Director? The ScrumMasters? Product Owners? The Team? Program and Portfolio Management? Executives? The answer, in my six years of personal Agile consulting experience, is ‘all the above.’ If they don’t ask about this at some point, it’s usually because they haven’t thought about it yet.

Why do they want an Agile Playbook?

Hopefully, because it adds value. This is the ‘So I can’ part of the story. It’s a guide to help them get where they want to go. It’s something we can point to when someone asks, “How are we doing Agile in our organization?” It’s something we can go to for reference when nobody else is around. It can even be used as an onboarding tool.

The Agile Playbook also gets us thinking not only about how we work, but how we can improve our processes. Are we really being empirical? Give it a little love in your retrospectives. Perhaps there’s an opportunity to update the Playbook. Oh, and if by chance you don’t see any value in it, simply don’t do it.

Yes, it’s a document.

OK, I know what many of you must be thinking by now… The Agile Manifesto says ‘Working software over comprehensive documentation.’ Yes, an Agile Playbook is a document. And yes, it’s likely to be pretty comprehensive. But that’s a relative term; more specifics on this will follow in a bit. The Agile Manifesto doesn’t say documents are evil. In this case, I believe it’s a very helpful and necessary document to have available in order to get everyone on the same page, and to show auditors that our processes are documented (they like that kinda stuff, ya know). An Agile Playbook is a big deliverable. It takes a lot of time, effort and know-how to put something like this together.

When I did one for a client a couple years ago, we employed a full-time Tech Writer for about a month. That was a huge help. I had initially tried to do it on my own, in my spare time, but that didn’t work out too well. The folks in the Agile PMO, including myself, provided the content, primarily.

But I’ve seen other organizations go with almost nothing documented, just pulling in a coach or two and letting it roll. Maybe sharing a few slide decks on an internal page. No strong desire to document the why, when and how we do stuff. I wonder if that’s because they hadn’t thought about it, didn’t want it by design, or just didn’t have the bandwidth. Or maybe there were other reasons. Personally, I believe that not documenting something this important to the agile transformation of your organization is irresponsible.

And having it documented – but all over the place in different formats – can be chaotic. I don’t like to make people go hunt down stuff, let alone guess or assume anything.

My opinion is that this should be as close to one document (or series of web pages) as possible, not multiples; i.e., not nine Powerpoint slide decks, seven Excel spreadsheets, and 12 Word documents with a bunch of buried links to even more documents, slide decks and spreadsheets. Make it as simple as possible. It’s one place to go. One thing to print off (if you desire to have a hard copy) and carry with you for reference. One URL to save as a favorite.

It can help us realize gaps in the way we work.

What I learned early on is that the hard work of creating an Agile Playbook forces us to give a long, hard look at the way we’re working now, and how we want to work in the future. It’s cathartic. It helps us identify areas where we can improve our processes. It forces us to ask some difficult questions. And make some difficult decisions.

One way in which to identify areas of improvement around your process is to identify your value streams. This is a basic Lean principle. I’m sure we’ve all done something like this. How efficient are we in going from start to finish (request to deployment, concept to cash)? Our goal should be to optimize this. Look to reduce delays, inefficiencies, and improve our cycle time.

How do we document tools and technical practices?

Let’s not forget how our tools and technical practices play into this, as they’re an important factor in how we get work done. If your organization is using an Agile Lifecycle Management tool, the Agile Playbook might include best practices on how to use that as well – either melded throughout, or as a separate section.

Same goes for development tools that help us with…

– Continuous integration – Jenkins, Hudson
– Defect Management – Bugzilla, JIRA, HP Quality Center
– Integrated Development Environment – Eclipse, Visual Studio
– Test Management – HP Quality Center
– Source Code Management – Git, Subversion
Agile Portfolio and Project Management – VersionOne, et al.

This can be a lot of information, so when documenting for the Agile Playbook, this is an area where I make heavy use of links to information beyond the basics of each of the tools we use.

It should be comprehensive, yet brief.

If you can’t fit the Agile Playbook into your front pocket comfortably, it’s probably too big. When I say brief, I mean about under 50 pages for a large organization. Any more than that, I think folks begin to feel overwhelmed and push it away. Any less, and it’s hard to be comprehensive. There’s no science behind that decision, but if I apply my own average attention span to the matter, this sounds about right. I think much of this also depends on the format you use: Microsoft Word, Powerpoint, HTML, etc. Again, where appropriate, I like to make liberal use of links to other documents/sources to help minimize the length. I recommend placing it on a well-known organizational site such as Wiki, Sharepoint, etc. Provide a highly visible and pronounced link from your internal company home page, and give the option of printing out a hard copy. In fact, I like to have several hard copies available in the Agile PMO to hand out to folks who want one. You’d be surprised how quickly they go. I’ve found that a nice ringed binder works best. That way, if there are changes, you can swap out a page or two. That said…

Did you know…

Most NFL teams now use tablets (iPad or Surface) almost exclusively for their Team Playbooks?

broncos-120423If you’ve watched ‘Hard Knocks’ on HBO, you already know that the phrase “Turn in Your iPads” has started replacing “Turn in Your Playbooks” when players are cut from an NFL team. Those teams have discovered that the technology goes far beyond the old playbook capabilities. There’s a product called ‘PlayerLync,’ which is at the forefront of this movement. It has revolutionized the way teams push out film and significantly altered the way they communicate. Beyond saving printing costs, digital playbooks are improving the effective, real-time communication by allowing coaches and quarterbacks to add and share plays with the click of a button. Every time new data, film or information is added, a banner alert pops up (like a text message), signaling players to view the updates.

Oh, and PlayerLync isn’t just for professional sports teams. Here’s a short clip on how Chipotle and others are using it to push content to their teams:

Uniqueness and commonalities

I’ve helped put together a number of these Agile Playbooks for different clients now, and each was both unique. But there are many commonalities, like the general Agile principles and practices. At the end of the day, folks want to know what to do, who does it, when to do it, and why. All these things can be exclusive to the organization or industry. The extent to which Scrum, Lean, and XP practices are applied also varies from company to company.


The fear seems to be centered around teams in an organization that are using both the framework and the tools differently. It could be that we’re not all using the Agile Lifecycle Management tool in the same way. How in the world can we expect to have rolled up views into the different management levels (Portfolio, Program, and Project) without a common agile project management tool? This opens the door to confusion on many levels, especially when we start talking about agile metrics/reports. But it’s not just the management level that has a problem if we’re not all on the same page. The individual team members also experience fear… fear of doing the wrong thing, or doing it incorrectly, getting called to the carpet or, worse yet, being publicly shamed, written up, or fired. The idea is that if we’re all on the same page, and everyone knows what’s expected, this fear diminishes greatly. Life gets better for everyone.

Start with an outline…

Finally, you were probably wondering when I was going to get here. By the way, each organization’s Agile Playbook is their own. I cannot share the exact Playbooks that I’ve put together with clients, as that information is proprietary. But I can share with you a more generic outline of what an Agile Playbook might look like:

About the Agile Playbook
What is Agile and Scrum?
Implementing Agile and Scrum at Company XYZ
Essentials of Agile and Scrum at Company XYZ (How ‘We’ Do It)
Agile Planning
Agile Execution
Agile Cultivation
Agile Tools
Agile Reporting/Agile Metrics
Staying Compliant with Agile
Company XYZ Communities of Practice (COP)

Do you have a Playbook for how you ‘do Agile’ in your organization? If so, what does it look like? If not, why?

Categories: Companies

Discovering Your Leadership Posted

Johanna Rothman - Mon, 01/19/2015 - 20:01

I published a new Pragmatic Manager this past weekend. It’s called Discovering Your Leadership.

It has a pointer to the Influential Agile Leader event that Gil Broza and I are leading in San Francisco and then in London. You can still get early bird pricing, until Feb 15. Don’t miss this opportunity—we’re only leading it twice this year.

Categories: Blogs

Using User Stories for Non-Functional Requirements

Scrum Expert - Mon, 01/19/2015 - 18:50
Non-functional requirements relate to qualities of the system that cut across user facing features, such as security, reliability, and performance. How does an Agile team take care of these non-functional requirements? This presentation discusses if user stories are of any use in this situation and how Scrum teams can applying Agile techniques to solve these concerns.Video producer: Further reading: Non-Functional Requirements: Do User Stories Really Help?
Categories: Communities

Agile Adria Conference, Tuheljske Toplice, Croatia, April 13-14 2015

Scrum Expert - Mon, 01/19/2015 - 16:16
Agile Adria Conference is a three-day conference that takes place in Croatia and focuses on Agile and Scrum. Its goal is as a regional event is to be the meeting point for Agilists from Croatia, Slovenia, Italy, Austria, Hungary, Serbia and Bosnia-Herzegovina. Speakers are experts coming from both Europe and the USA. Among the expert for the Agile Adria conference, you will find known authors like Marry Poppendick and Sephen Parry. In the agenda of the Agile Adria conference,  you can find topics like “How to improve estimates for software: The #NoEstimates ...
Categories: Communities

VAST – Virtuous Cycle for Connection

Agilitrix - Michael Sahota - Mon, 01/19/2015 - 15:57

It’s all about how we show up. If we show up in a way that invites people to connect, to trust, to feel safer than usual, they probably will. And astonishing results will follow. Olaf and I have a vast experience of limiting our results because we didn’t dare to show up, speak up, stand up. We’ve been not daring, not trying, not challenging, most of our lives—like most people! We’ve learned the hard way how to show up in a way that enables connection, and impact.

We use the VAST cycle to increase connection to grow engagement in the workplace. We know safety and trust are important, but that is not the whole story. We need whole humans, intensely connected, to unleash the co-creation of astonishing results.

Joint post with Olaf Lewitz.

VAST Cycle Virtuous Cycle for Connection

Virtuous Cycle for Connection

Authentic Connection

How to use VAST for Yourself

We use VAST as a way to navigate relationships. It works in personal and professional contexts.

Use VAST for introspection: In relation to another, we may ask ourselves:

  • How trusting am I?
  • How safe do I feel?
  • How connected do I feel?
  • How vulnerable am I choosing to be?
  • Am I acting authentically?

With this new awareness, the model suggests a variety of moves:

  • I can choose to be vulnerable and share how I feel. How I am feeling unsafe. How I am not trusting.
  • I can choose to trust the other person and see how my behaviour shifts.
  • I can state what I want. “I want to restart this conversation. I want to focus on how we can support each other. I want to focus on the goal.”
  • I can ask for help.

In our experience, the most powerful move is vulnerability. Owning our experience and how we feel and then sharing it really kicks off the cycle. That’s what we mean by showing up.

I have a short video explanation of VAST in my People over Process talk.

VAST for Organizations

We use VAST to build awareness and choice for organizations. It is especially useful when contrasting with organizational debt (fear, mistrust) as a way of being.

A team, group, or organization may choose VAST as a future way of being. The cycle helps guide behaviour and create ideas for experiments.

We can use it in retrospectives, to collect narratives that demonstrate the behaviour we want. Acknowledge when someone was daring, inspiring us to move forward.

Run a Temenos lab to experience the cycle for yourself or with your team.

Origins of VAST

The VAST cycle is the result of a sense-making journey between Olaf and I over the past years. We have been learning and studying its elements to help ourselves and our clients grow. We didn’t go out to invent something, it just emerged – it’s a discovery. We then noticed how well it explains many beautiful personal and professional growth experiences with ourselves and our clients.

The term “VAST” was created by Anton Gillis-Adelman – who is an expert in turning a jumble of letters into words.

Related Work

The post VAST – Virtuous Cycle for Connection appeared first on Catalyst - Agile & Culture.

Related posts:

  1. Organizational Debt Cycle Many consider the modern workplace inhumane and uninhabitable. People are...
  2. People over Process – Win with People Success comes from Valuing People When we simplify the Agile...
  3. WholeHearted Manifesto: We Value People The WholeHearted Manifesto consists on one value statement: We Value...

YARPP powered by AdBistroPowered by

Categories: Blogs

Try is free in the Future

Xebia Blog - Mon, 01/19/2015 - 10:40

Lately I have seen a few developers consistently use a Try inside of a Future in order to make error handling easier. Here I will investigate if this has any merits or whether a Future on it’s own offers enough error handle.

If you look at the following code there is nothing that a Future can’t supply but a Try can:

import scala.concurrent.{Await, Future, Awaitable}
import scala.concurrent.duration._
import scala.util.{Try, Success, Failure}

object Main extends App {

  // Happy Future
  val happyFuture = Future {

  // Bleak future
  val bleakFuture = Future {
    throw new Exception("Mass extinction!")

  // We would want to wrap the result into a hypothetical http response
  case class Response(code: Int, body: String)

  // This is the handler we will use
  def handle[T](future: Future[T]): Future[Response] = { {
      case answer: Int => Response(200, answer.toString)
    } recover {
      case t: Throwable => Response(500, "Uh oh!")

    val result = Await.result(handle(happyFuture), 1 second)

    val result = Await.result(handle(bleakFuture), 1 second)

After giving it some thought the only situation where I could imagine Try being useful in conjunction with Future is when awaiting a Future but not wanting to deal with error situations yet. The times I would be awaiting a future are very few in practice though. But when needed something like this migth do:

object TryAwait {
  def result[T](awaitable: Awaitable[T], atMost: Duration): Try[T] = {
    Try {
      Await.result(awaitable, atMost)

If you do feel that using Trys inside of Futures adds value to your codebase please let me know.

Categories: Companies

Knowledge Sharing

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