Skip to content

Feed aggregator

Project Management with Kanban Class Curriculum

This is the first look at one of our new role-based training classes. This is specifically targeted at project managers and related roles such as service delivery manager, program manager, and anyone with responsibility for delivering projects, product releases and similar batches of packaged creative or knowledge work. This new curriculum is scoped within the Modern Management Framework and will be available in 2-day class format at the Advanced Practitioner level with the LeanKanban University curriculum structure. Project Management with Kanban classes will be available publicly and privately from October 1st 2014 from David J. Anderson & Associates. From November 1st, and Accredited Advanced Kanban Trainer (AAKT) will be able to offer the class through the LeanKanban University certified training program.

read more

Categories: Companies

10 High-Value Activities in the Enterprise

J.D. Meier's Blog - Sat, 09/06/2014 - 22:59

I was flipping back over the past year and reflecting on the high-value activities that I’ve seen across various Enterprise customers.  I think the high-value activities tend to be some variation of the following:

  1. Customer interaction (virtual, remote, connect with experts)
  2. Product innovation and ideation.
  3. Work from anywhere on any device.
  4. Comprehensive and cross-boundary collaboration (employees, customers, and partners.)
  5. Connecting with experts.
  6. Operational intelligence (predictive analytics, predictive maintenance)
  7. Cross-sell / up-sell and real-time marketing.
  8. Development and ALM in the Cloud.
  9. Protecting information and assets.
  10. Onboarding and enablement.

At first I was thinking of Porter’s Value Chain (Inbound Logistics, Operations, Outbound Logistics, Marketing & Sales, Services), which do help identify where the action is.   Next, I was reviewing how when we drive big changes with a customer, it tends to be around changing the customer experience, or changing the employee experiences, or changing the back-office and systems experiences.

You can probably recognize how the mega-trends (Cloud, Mobile, Social, and Big Data) influence the activities above, as well as some popular trends like Consumerization of IT.

High-Value Activities in the Enterprise from the Microsoft “Transforming Our Company” Memo

I also found it helpful to review the original memo from July 11, 2013 titled Transforming Our Company.  Below are some of my favorite sections from the memo:

Via Transforming Our Company:

We will engage enterprise on all sides — investing in more high-value activities for enterprise users to do their jobs; empowering people to be productive independent of their enterprise; and building new and innovative solutions for IT professionals and developers. We will also invest in ways to provide value to businesses for their interactions with their customers, building on our strong Dynamics foundation.

Specifically, we will aim to do the following:

  • Facilitate adoption of our devices and end-user services in enterprise settings. This means embracing consumerization of IT with the vigor we pursued in the initial adoption of PCs by end users and business in the ’90s. Our family of devices must allow people to be more productive, and for them to easily use our devices for work.

  • Extend our family of devices and services for enterprise high-value activities. We have unique expertise and capacity in this space.

  • Information assurance. Going forward this will be an area of critical importance to enterprises. We are their trusted partners in this space, and we must continue to innovate for them against a changing security and compliance landscape.

  • IT management. With more IT delivered as services from the cloud, the function of IT itself will be reimagined. We are best positioned to build the tools and training for that new breed of IT professional.

  • Big data insight. Businesses have new and expanded needs and opportunities to generate, store and use their own data and the data of the Web to better serve customers, make better decisions and design better products. As our customers’ online interactions with their customers accelerate, they generate massive amounts of data, with the cloud now offering the processing power to make sense of it. We are well-positioned to reimagine data platforms for the cloud, and help unlock insight from the data.

  • Customer interaction. Organizations today value most those activities that help them fully understand their customers’ needs and help them interact and communicate with them in more responsive and personalized ways. We are well-positioned to deliver services that will enable our customers to interact as never before — to help them match their prospects to the right products and services, derive the insights so they can successfully engage with them, and even help them find and create brand evangelists.

  • Software development. Finally, developers will continue to write the apps and sites that power the world, and integrate to solve individual problems and challenges. We will support them with the simplest turnkey way to build apps, sites and cloud services, easy integration with our products, and innovation for projects of every size.”

A Story of High-Value Activities in Action

If you can’t imagine what high-value activities look like, or what business transformation would look like, then have a look at this video:

Nedbank:  Video Banking with Lync

Nedbank was a brick-and-mortar bank that wanted to go digital and, not just catch up to the Cloud world, but leap frog into the future.  According to the video description, “Nedbank initiated a program called the Integrated Channel Strategy, focusing on client centered banking experiences using Microsoft Lync. The client experience is integrated and aligned across all channels and seeks to bring about efficiencies for the bank. Video banking with Microsoft Lync gives Nedbank a competitive advantage.”

The most interesting thing about the video is not just what’s possible, but that’s it’s real and happening.

They set a new bar for the future of digital banking.

You Might Also Like

Continuous Value Delivery the Agile Way

How Can Enterprise Architects Drive Business Value the Agile Way?

How To Use Personas and Scenarios to Drive Adoption and Realize Value

Categories: Blogs

Proper Error Handling In ExpressJS Route Handlers

Derick Bailey - new ThoughtStream - Sat, 09/06/2014 - 21:35

For a long time now, I’ve been brute-force ugly with my error handling in my ExpressJS apps. Basically, just throw the exception after it bubbles back up to the route handler.

This works. If you don’t mind the app completely blowing chunks at this point and dumping itself entirely.


Of course, you could put a global error handler in your code to catch this unhandled exception, and *not* exit the app. But this is probably a bad idea, too. Once an exception is thrown (and not handled by the code that was being called, in the first place), the NodeJS environment is basically in an unknown and potentially bad state.

Handle It Properly

Unhandled exceptions should be allowed to crash and exit the app. Therefore, you really want to handle this exception in your callback, properly.

It’s a simple change, but using “return next(err);” instead of “throw err;” allows asynchronous code to raise an exception and still have it caught by the error handling pipeline in your app. Instead of putting the app into an unknown state where everything is potential dead or dangerous, calling “next(err)” tells the Express and Connect frameworks to pass the error along until an error handling middleware of function can properly take care of it. 

Error Handler Middleware

If you weren’t aware of it, every ExpressJS app comes with an error handler (or two – one for development work, one for non-development work… “production” … by default) in the default app.js file that is generated by the express command line:

This code properly handles an error that was sent up the line using the “return next(err);” style of handling. Instead of putting the app in to an exception state by throwing the error, it is properly handled by the middleware, allowing you to write your own custom code, error logging and rendered view in response to the error ocurring.

More On Error Handling

There are potentially a lot more advantages to doing things this way, centered around application design and code architecture. But I’ll leave those for other discussions. 

If you want to read more about proper error handling, check out this article on error handling in NodeJS, from Joyent (thanks to Peter Lyons for pointing this one out):

@derickbailey This article is the bible of error handling in node:

— Peter Lyons (@focusaurus) September 6, 2014

Now if you’ll excuse me for a moment, I’ve got to go clean up some error handling code in my apps.

     Related Stories 
Categories: Blogs

Is Agile the finger or the moon?

On the Gemba Academy podcast, Michael Balle mentioned something that car designers have learned:
The feel of silence is not the absence of noiseIn other words, although the formal definition of silence is the absence of noise, "silence" as a human experience is something different.

This reminds me of a similar phenomena with religions, for example, nominally Theravada Buddhism emphasises original, formal expression of scripture while nominally Mahayana Buddhism emphasises empirical validation and the experience of Buddhism.

In other words, instead of the formal definition of Buddhism as described in scripture, one might emphasise "Buddhism" as a human experience.  The feel of Buddhism is not found in the scripture.

A relatively well-known analogy is that of a finger pointing to the moon.  The point is to see and experience the moon, not the finger.

How might this apply to this thing we call Agile?  Is the feel of Agile found in the Manifesto?

What is the feel of Agile as opposed to the formal definition? What is the Agile moon versus the Agile finger?

I touched on something similar when exploring Agile doctrine but in this case, let's approach things from the perspective of "feeling".

This is what I think captures the essence of the experience and feel of Agile.  My attempt at a better "finger" if you will:
  1. Empathy and insight created by problem solvers being close to the people and situations that have the problems they're trying to solve.
  2. A sense of safety and confidence created by breaking down larger problems into smaller steps and validating each step.
  3. A general feeling of dissatisfaction leading to and reinforced by a habit of continuous improvement.
Categories: Blogs

Kanban Coaching Professional Masterclass Curriculum

For the first time, I'm posting our curriculum for the Kanban Coaching Professional Masterclass. This new curriculum is scoped within the Modern Management Framework and takes effect in Masterclasses offered after November 1st 2014.

read more

Categories: Companies

Those are Not MY Impediments!

Agile Tools - Sat, 09/06/2014 - 02:34

Army Boots Stand Out in a Crowd









When trying to find impediments there is a trap that awaits those of us who are outside of or observing the team. Often, when you are observing a team as an outsider, you may think you see patterns of behavior and obvious disfunction. Naturally enough, not being part of the system often gives us a fresh perspective from which to see problems within a team. Often I have found myself able to rattle off a list of issues that I see a team dealing with after observing them for only a few minutes. Some patterns of team disfunction are suspiciously easy to detect. But wait, here comes the trap. So you make a list, maybe write up a few recommendations and share your “gift” with the team. What team wouldn’t appreciate someone kind enough to share a list of all the ways they suck?


It doesn’t matter if you are right (and you probably are at least 50% of the time). Best case, the team thanks you for your honesty. Worst case, they kick you out of their standup and tell you never to come back. In any case, they aren’t very likely to take your suggestions seriously. The thing about impediments is, in order to really own them and take them seriously, they need to be something the team genuinely care about – and most likely they should be the team’s idea. Ownership is important, because often impediments are pretty tough to deal with, so you need to be really committed if you expect to resolve them.

Often, what I think I see are two different lists of impediments: the scrum master, coach or manager’s list, and the team’s list. The scrum master is scratching their head wondering, “How can I get these guys to engage with these impediments?” Meanwhile, the team is thinking, “Do you really want to eliminate an impediment? Fire a scrum master!”

So I guess the lesson here is that often nobody is all that interested in what you think the impediments are. They already know what the impediments are. They’re just waiting for someone to really listen.

Filed under: Agile, Coaching, Scrum, Teams Tagged: Agile, coach, Impediments, Team
Categories: Blogs

Lean-Kanban at Scale

Al Shalloway, CEO of Net Objectives, discusses how to apply Lean-Kanban at scale to manage software initiatives more effectively. About this Webinar The essence of Kanban is to manage the workflow of value added activities by limiting how much work is being done. Al uses Lean thinking to extend Kanban to the portfolio, program, and team […]

The post Lean-Kanban at Scale appeared first on Blog | LeanKit.

Categories: Companies

Anatomy of the Kanban Canvas

AvailAgility - Karl Scotland - Fri, 09/05/2014 - 21:55

I’ve just added a high level explanation of the anatomy of the Kanban Canvas to the main Kanban Thinking site (where you can downloade the Canvas). I thought I would also post it here.


How to assess the systemic problem and who is experiencing it.

At the centre of the Canvas is the system being worked on.

Assuming that the current situation is not perfect, and there is always room for improvement, then understanding the scope of the system helps focus on the biggest opportunities for improvement and avoids “rearranging the deck chairs on the Titanic”. By thinking about the situation as part of a holistic system, and having clarity on the scope of the system, we are more likely to identifying opportunities which improve the whole, rather than making smaller, local improvements, which might worsen the whole.

This leads to the question of what is the scope of the system. Defining the system to be too small, might not lead to any significant improvements. Equally defining the system to be too large, might be like trying to “boil the ocean”.

One way of understanding the system is to look at the people involved, and explore what problems those people are having. Narrative is an extremely useful form of doing this – finding and telling stories about people’s experiences and frustration with their work. In particular, the stories related to the customers and stakeholders will start to identify the boundaries of the system.

One fun way of exploring the system through narrative is by using the Pixar Pitch. This approach makes the final “Because of that…” refer to the current kanban system design, and the “Until Finally…” is left blank to be explored in the Impact section.


How to assess the fitness criteria in terms of flow, value and potential.

The three arrows coming out of the right of the central System are potential Impacts which might be made. These Impacts encourage a focus on what success or failure could look like, before any changes get made.

Given that in most situations, we are dealing with complex problems, where cause and effect are only apparent with hindsight and past solutions are not necessarily repeatable in the future, then we should not try to define a specific future state to solve the problem. However, that does not mean that we cannot determine the characteristics of the outcomes of solutions so we can assess their fitness criteria, or how fit for purpose a solution is.

Impact is an evaluation of fitness for purpose. A successful solution is one which has positive impact and an unsuccessful solution is what which has negative (or no) impact. Impact can be thought of as direction, as opposed to a point solution being a specific destination.

Having explored the scope of the System through narrative, we can also begin to define Impact in a similar way by asking what stories do we want to hear more of, or less off, in the future. When using the Pixar Pitch technique, imaging impossible good and bad endings to the story brings out exaggerated scenarios which can be compared against by asking whether the System is becoming more or less like the suggested endings. Getting both good and bad endings allows both positive and negative Impact to be easily imagined and identified.

When imagining the future, to create a range of diverse possibilities, the Impacts on Flow, Value and Potential are used to encourage thinking from different perspectives.


How to assess the evolutionary potential in terms of studying, sharing, stabilising, sensing and searching.

The five arrows going into the left of the System are the potential Interventions that could be made. These Interventions provide a frame for appreciating the intent behind various practices, learning and discovering which ways of working are the right ones for the current situation, and transforming those practices as the system continuously evolves.

Working through the interventions encourages continuous curiosity about which tools and techniques to use, understanding when and why they are appropriate, and ultimately collaboratively, co-creating an initial kanban system as a baseline to begin experimenting and improving.

The interventions used are to Study the context, Share the understanding, Stabilise the work, Sense the capability and Search the alternatives.

Categories: Blogs

Software Developers Are Storywriters

Agile Thinks and Things - Oana Juncu - Fri, 09/05/2014 - 21:04
WALL.E - a Pixar MovieOften ( always? ) developers are perceived ( even by themselves !) as translators of  requirements into code. The art and craftsmanship of developers is recognised in respect with the "skilfulness" of their translation : Clean Code,  Test Coverage,  Test Driven Development , Design Driven Development, and so on. But developers are not only translators,  they are the real writers of  the software product story they are about to code . Agile User Stories,  Wall-E  and T-StoryOne of Agile's favorite artefacts is the User Story . Every member of an Agile Team works on User Stories. Well..hmmm? Do they ? Is it really so? How many "User Stories" like that did you see :
"As the e-B3-threadComputing I need to call the GarbageCollector in order to improve my memory management performance with 30%"
WOW ! When I first read a story like that I thought : "Great , this is a product about robots and this user story is about E-VE falling in love with WALL-E". As Pixar created "Toy Story",  Agile Software Development invented the T-Story ( as "Technical" , of course ) . Some time after meeting the first T-Story of my life I became confused.... Because there were many of them... in all software products, regardless of the company's business that develops that software.Now, that's interesting,  how come all humans in the world need exclusively products about wall-E , E-Ve and their cousins? How that did happen?! 
 Refactoring the Mindset My little idea is that it happened because organisations and companies treated software developers as "translation automates" of  "functional requirements" in programming languages.  The outcome of this mindset is a target product that is about automates . And the first version of the product risks high to leave business people speechless on a puzzle question : "How the hell did they build such an absurd product "?  Well, business people, they built a robotic product that highly make little sense from an user perspective because we might have treated developers as producers of "abstractions".If we want to build products that make sense for humans, there is one think to refactor : the "automate translation" mindset. And grow a software development culture that acknowledges that software products are stories about real people .
Software Products Are Stories About HumansThe "User" side of "User Story" is the key of a great software. Gojko Adzic says that un-experienced teams create T(ethnical) -stories instead of user stories. I think is more than experience , is a question of mind set. Just shift your mind from the T-Story to a real person next to you that experiences the service you're about to implement and think about how does that feel differently.  The mind shift from technical layers and composants to small pieces of code that are meaningful from a user experience perspective is hard. Nevertheless , the only way to build shippable products at the end of each sprint is to stick to this rule : every user story is a new - enhanced- experience for the user. How to do that ? If you like methods, Gojko defined the Hamburger Method . It's my favorite.  Beyond the "How to" , though, the secret of succeeding is the way we think about the software protect.  Because it's not a collection of code,  it tells a story where human users are heroes.This is  why I strongly believe software developers are writers of stories co-created together with Product Owners, Business People and whoever needs to hang around. Agile people say teams are more performant when they are collocated. If this is true it is because the fireplace where products stories are told needs to stay vivid. The software code embeds a story. Would you like the story your code tell to be awesome ?

Categories: Blogs

Forget The Other. Show Me What You’ve Got - Fri, 09/05/2014 - 17:19

Put makeup on your own pig, make it look as good as you can. Don’t go around finding ugly imaginary pigs to stand it beside.

Warning: This article may contain sarcasm and ranting.

Do you have a good idea about how to express something that those guys said a decade and a half ago? Well, then, just say it. You could even set it in context. Here are two ways to do it. One of them is much better than the other in my opinion.

Don’t do this

“Individuals and interactions over processes and tools.” That may have been all they knew way back last century, but today we know a hell of a lot more. The real idea is to make decisions about processes and tools at the right level. Often that level is well above the pay grade of the so-called “team”. (And so on.)

Instead, do this

“Individuals and interactions over processes and tools.” Here’s one way I like to work with that Agile Manifesto value. We need many tools in the doing of our work. Wherever possible, I like to let each team select its own tools and process. There is a need for consistency in a few areas, but fewer than you might think. (And so on.)

What’s going on?

The first approach tries to set you up as smarter than those other guys. You’re trying to set yourself off from others, by tearing them down. Tearing down the other person doesn’t make you taller: it makes you seem small. Maybe your idea is better. Maybe you are smarter. Let your idea show how smart you are. And why set up opposition for yourself. Some people value those old ideas. Do you really want to start by telling them they’re wrong?

The second approach builds on the good things in the past. Referring to the past that way lets you associate yourself with ideas people respect, and makes your ideas seem to fit in with what people already know and care about. You reduce resistance to what you’re saying, making it easier for people to hear you.

Straw Man

I often tweet reminders about the straw man from time to time, referring to this picture, entitled “Idea looking comparatively good next to a straw man.


Keep your straw man. Just tell me what you think. There is no need to quote — or more likely misquote — someone else to make your idea look better to me.

Exemplum Docet – or, A Rant Begins Here

OK, that said, I’m going to put down some straw men of my own, entirely made up examples no one really said. No one would say them, I’m sure. They’re just made up examples of what not to do, because I need to rant today.

I hate those guys who push Idea X. They’re just doing it for the money. I’m glad I took the high road.

Yeah, well, intercourse you and your penguin. The people who push IdeaX mostly believe in it at least as much as you believe in … in … what is it you believe in, actually? Are you just here to whine about those other unnamed people? Is the problem really that they’re just doing it for the money, or might it be something closer to home, like regret for your own past pathetic decisions? Get over the past. Tomorrow is a new day.

Are you really satisfied with your life? If so, tell me how you managed it. Or are you jealous of someone else’s life? Keep that to yourself.

Those guys had a good idea back at the beginning of the century but what they said should be updated to what we know now.

See previous advice regarding your aquatic flightless bird. Instead of whingeing about what somebody who isn’t you did years ago, why not come up with an idea or two of your own? And instead of using your critique of those people to launch your wondrous and doubtless fascinating advice, come up with a new name.

Tell me your idea. Maybe you can even find 13 other people to help you create your marvelous new idea. Get it out there. See if it can stand the test of time.

Some people think Stupid Idea A. I teach Smart Idea B. Hahaha on those other guys. I am smarter than they are.

Where are all these fish-reeking black and white flappy creatures coming from? It’s starting to bug me. No one with even minimal credibility ever supported Stupid Idea A. You twisted the words of ten smart and sincere people to create that ridiculous idea, which is held by exactly no people anywhere. You aren’t just trying to make yourself, and your idea look good, by any chance?

Just tell me your smart idea. No need to set it up by surrounding it with stupid ideas that your readers don’t believe anyway.


Make your own lawn look good. Stop throwing trash onto mine.

Categories: Blogs

Hello managers, coaches, and other change agents

Henrik Kniberg's blog - Fri, 09/05/2014 - 16:28

Here’s the thing. Suppose you introduce a change X to your workplace, and then business improves noticably. That doesn’t mean X caused the business to improve. Well, MAYBE it did. Or perhaps business improved for other reasons, and X was actually detrimental, and business would have improved even more without it. So did things work out well because of the great X, or despite the lousy X? You’ll never know, unless you could rewind the clock and play out the same scenario without X. Correlation doesn’t imply causation.

So people like me who work with organizational change, we are in the business of pseudo-science. We get customer feedback and anecdotal evidence, but we can’t actually prove that we are doing any good, it’s just opinions and observations and guesswork. I think that’s fine, but let’s be honest about it :)

Categories: Blogs

Event Report – Product Owners: Dealing with Capacity and Prioritisation

Scrum User Group of South Africa - Fri, 09/05/2014 - 10:15
Last night’s talk by Karen and Sam from Growing Agile was an inspirational eye-opener for Product Owners. It was also one of the best attended events with 80 Agilists present! Sam and Karen co-presented the event, using a highway as an analogy for capacity. Their slides were refreshingly hand-written. Of course, the mingling after the […]
Categories: Communities

Product Ownership – Dealing with capacity and prioritisation

Growing Agile - Fri, 09/05/2014 - 09:03

Last night we did a talk for SUGSA (the Scrum User Group of South Africa). It was a blast and full of eager learners icon smile Product Ownership   Dealing with capacity and prioritisation

We spoke about 2 techniques – one to talk and understand capacity and one to assist with prioritisation. The slides are on slideshare.

And you can read about the techniques, The Freeway Analogy and Prioritise your Backlog. This post might also help: A Handy Guide for Coaching Product Owners.

If you are keen to read about more of these workshops, please buy our books!

BookAR 300x300 Product Ownership   Dealing with capacity and prioritisationBookMB 300x300 Product Ownership   Dealing with capacity and prioritisationBookRP 300x300 Product Ownership   Dealing with capacity and prioritisation

 Here is a writeup from the committee:

Categories: Companies

Is Improvement really Continuous?

Agile Tools - Fri, 09/05/2014 - 05:38








I don’t want to get on a rant here, but…In the Agile community and perhaps in the IT community in general there is a tendency to use the term “Continuous Improvement” to describe some sort of mythical state where teams are constantly evolving toward some state of perfection. At least that’s what I think of when I hear the term. Now I don’t know about you, but I don’t think I’ve ever seen such a creature in the wild (or even anything close to it). Furthermore, I’m concerned that using such terminology sets an unrealistic expectation for performance with our customers and stakeholders.

As an example, I’ll use myself. Right now, despite a host of good intentions on my part, I am not continuously improving. I’m typing – my spelling and grammar are showing no discernible sign of improvement (as I’m quite sure you, dear reader, are all too painfully aware of). Honestly, I’m just not improving right now. In fact, I haven’t done anything to improve my blog writing since the last time I wrote one a week ago…a month ago…6 months ago…

“But Tom don’t be so hard on yourself!” You say, “Just by writing more you are improving your writing skill and the content of the blog.” To this my answer would be, “So just writing more code is improving too?” We all know the answer to that question. So no, the only thing writing does by itself, is make the number of words on the page grow.

In fact, I have a confession to make. Nothing I plan to do in the next 24 hours has anything with improvement. Not even:

  • Attending meetings (generally the opposite of improvement)
  • Writing status reports (ditto)
  • Cleaning the house (status quo – just fighting entropy is not improvement)
  • Commuting (status quo)
  • Watching TV (gently sliding toward entropic oblivion)
  • Sleeping (mandatory, but not improvement, at best it’s re-establishing the status quo)

You see, true improvement is really hard work, therefore I don’t do it very often. I certainly have never been able to do it “continuously”. Hah! What a ridiculous notion that is! Nobody can improve continuously. We all need to take a break. Taking a break is actually necessary in order to improve! So the very term “continuous improvement” is at best misleading and at worst an idiotic notion. It can’t be done! Combining the terms continuous and improvement is like the old joke about the term military intelligence – it just doesn’t exist!

Up to this point I’ve just been ranting about continuous improvement, but in the Agile community we use the “continuous” word everywhere. There’s continuous integration, continuous delivery, and I’m sure there are a few more I haven’t even thought of. Take any one of those continuous activities and look at it closely enough, and guess what? Not much is happening. I’m willing to bet that your continuous integration server isn’t constantly running builds all the time (at least I hope not). I’m sure the average integration server spends a lot of time just waiting for the next build request. I hope by now it is pretty apparent that very few things are really continuous. I think we need a better term to describe these processes. I would propose: Periodic, Frequent, Event-driven or my personal favorite – on demand.

I know, I really do get it – continuous sounds just better. Continuous has an aspirational sort of quality to it which you can’t help but admire. I think that it’s just a little disingenuous to use that term for things that may not even take place for an hour or even a day at a time. If improvement is really continuous in nature, I want to see evidence of improvement taking place as I’m watching, when my back is turned, on weekends, and perhaps even when visiting the bathroom. Is that too high a bar to set? I don’t think so. I make that demand of my lowly alarm clock. I’m not saying improvement doesn’t take place. It happens – for some of us it happens pretty frequently. For others, it happens on demand at the end of the sprint.

Improvement may be a never-ending quest, but it is rarely, if ever, continuous.

Filed under: Agile, Scrum Tagged: Agile, Continuous Improvement, Process
Categories: Blogs

LeanKanban Kanban Foundation Curriculum

As part of our continuing sneak peak of the new LeanKanban Modern Management Framework, I want to show how we are using it to define and communicate the curriculum for individual training classes. We are now offering a wide range of training classes at different levels. Here we look at the 2-day Kanban Foundation level training...

read more

Categories: Companies

The Agile Reader – Weekend Edition: 09/05/2014 - Kane Mar - Fri, 09/05/2014 - 04:45

You can get the Weekend Edition delivered directly to you via email by signing up

The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.

  • Read This #Book : #Kindle #4639

    The Scrum Checklist, For the Agile Scrum Master, Product Owner, Stakeholder and…

  • RT @agiledeveloper: Scrum Expert: Agile Bodensee, Constance, Germany, October 1–2 2014 #agile
  • We are hiring: Agile Transformation Coach Agile Transformation Coach (Pont #job @Hewlett-Packard #Agile #Scrum
  • New blog post: Estimating Story Points #ScrumPadawan #agile #scrum
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#Chennai) #job
  • Accenture is hiring a Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#Chennai) #job
  • Accenture #job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#Chennai)
  • We’re hiring a Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#Chennai) #job
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#Chennai) at Accenture #job
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) #job (#Chennai)
  • RT @acc_us: #Agile Coach Camp is Sept 26-28 in Indianapolis, IN. Get your tickets now. #Scrum #PM #pmot…
  • What I’ve Been Readin, Writin, and Playin With #Scrum #Agile
  • Read This Book : #Kindle #8393

    Scrum Shortcuts without Cutting Corners: Agile Tactics, …

  • Read This Book #9: Succeeding with Agile: Software Development Using Scrum Kindle #271


  • Read This Book #6: The Scrum Field Guide: Practical Advice for Your First Year (Agile So…
  • Read This Book #1: Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips…
  • RT @ScrumDan: Embrace Change + Learn from Mistakes = Successful Agile Implementation #agile #scrum
  • Struggling with Scrum? Try Kanban. #Agile #Scrum #Kanban
  • Read This Book : #8: Succeeding with Agile: Software Development Using Scrum #Kindle #03
  • Read Now : #8: Succeeding with Agile: Software Development Using Scrum #Kindle #814
  • Read #Book : #1: Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips… #Kindle #5662
  • Read #Book : #8: Succeeding with Agile: Software Development Using Scrum #Kindle #5662
  • Read This Book : #6: The Scrum Field Guide: Practical Advice for Your First Year (Agile Software… #Kindle #03
  • Read #Kindle #6: The Scrum Field Guide: Practical Advice for Your First Year (Agile Software Development… #098
  • Read Now : #6: The Scrum Field Guide: Practical Advice for Your First Year (Agile Software… #Kindle #814
  • Read #Kindle #8: Succeeding with Agile: Software Development Using Scrum #098
  • Read Now : #1: Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips (Addison-Wesley… #Kindle #188
  • Read Now : #8: Succeeding with Agile: Software Development Using Scrum #Kindle #9991
  • Read This Book #6: The Scrum Field Guide: Practical Advice for Your First Year (Agile Software… #3902 #Kindle
  • Read This Book #8: Succeeding with Agile: Software Development Using Scrum #3902 #Kindle
  • #Kindle #1: Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips (Addison-Wesley… #88162
  • #Kindle #8: Succeeding with Agile: Software Development Using Scrum #88162
  • Read This Book #6: The Scrum Field Guide: Practical Advice for Your First Year (Agile Software… #34774 #Kindle
  • Read This Book #8: Succeeding with Agile: Software Development Using Scrum #34774 #Kindle
  • Read This #1: Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips (Addison-Wesley… #290 #Kindle
  • Read This #6: The Scrum Field Guide: Practical Advice for Your First Year (Agile Software… #290 #Kindle
  • Read This Book #8: Succeeding with Agile: Software Development Using Scrum #04 #Kindle
  • Read Now : #8: Succeeding with Agile: Software Development Using Scrum #Kindle 3341
  • Read Now : #6: The Scrum Field Guide: Practical Advice for Your First Year (Agile Software… #Kindle #400
  • Read Now : #1: Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips (Addison-Wesley… #Kindle #400
  • Read This Book #8: Succeeding with Agile: Software Development Using Scrum #042312 #Kindle
  • Read This Book #1: Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips… #765 #Kindle
  • RT @ScrumDan: Struggling with Scrum? Try Kanban. #Agile #Scrum #Kanban
  • Read #341 #Kindle

    The Scrum Field Guide: Practical Advice for Your First Year (Agile So…

  • Read #341 #Kindle

    Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips…

  • excited RT @jeffsutherland: Scrum: The Art of Doing Twice the Work in Half the Time is out in the UK. #scrum #agile
  • 9 Interviewing Tips To Get Inside Your Users’ Heads: – UXmatters #ux #agile #scrum #pmot #pm
  • How Agile, Waterfall, Scrum and Enterprise Project Management fit together!
  • RT @acc_us: #Agile Coach Camp is Sept 26-28 in Indianapolis, IN. Get your tickets now. #Scrum #PM #pmot…
  • READ BOOK > # Kindle #61 #6: How to Become a Scrum Master in 7 Simple Steps (Agile Proje…
  • READ BOOK > # Kindle #61 #3: The Scrum Checklist, For the Agile Scrum Master, Product Ow…
  • RT @ScrumDan: Struggling with Scrum? Try Kanban. #Agile #Scrum #Kanban
  • Read this #Kindle #8399

    Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, …

  • From the blog archive: How much will it cost and when will I get it? #noestimates #agile #pmot #lean #scrum #kanban
  • RT @rhundhausen: #Agile means getting rid of test teams. That’s what Microsoft did #scrum #proscrumdev
  • Read This Book #Kindle #9948

    The Power of Scrum, In the Real World, For the Agile Scrum…

  • Read This Book #Kindle #9948

    Scrum, (Mega Pack), For the Agile Scrum Master, Product Ow…

  • Read This Book #Kindle #9948

    Scrum Essentials: Agile Software Development and Agile Pro…

  • Read This Book #Kindle #9948

    How to Become a Scrum Master in 7 Simple Steps (Agile Proj…

  • Read This Book #Kindle #9948

    The Scrum Checklist, For the Agile Scrum Master, Product O…

  • RT @neil_killick: From the blog archive: How much will it cost and when will I get it? #noestimates #agile #pmot #l…
  • From the blog archive: What if I can’t work with #NoEstimates? #agile #scrum #pmot #baot #lean #kanban
  • RT @neil_killick: From the blog archive: What if I can’t work with #NoEstimates? #agile #scrum #pmot #baot #lean #k…
  • RT @HPappsServices: Agile Scrum isn’t a silver bullet solution for s/w development, but it can be a big help. #Apps…
  • Everyone has been asking me to sell my user Story Cards. #agile #scrum
  • #IT #Ops tends to have crunch times around major implementations, outages, and production releases #agile #scrum
  • #RT #AUTHORRT #scrum that works ** ** #agile #project #productowner
  • Slides da minha palestra no @SGRIO2014 #sgrio2014 #agile #integração via @SlideShare
  • Read This #Book : #Kindle #553

    Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips (Addison-W…

  • We’re heading to the Agile Nashville Meetup this Monday at noon. Are you? @AgileNashville #agile #lean #scrum
  • Agile by McKnight, Scrum by Day is out! Stories via @zeroload @rhundhausen
  • Check This BOOK #71202 #Kindle

    The Power of Scrum, In the Real World, For the Agile Scr…

  • Check This BOOK #71202 #Kindle

    Scrum, (Mega Pack), For the Agile Scrum Master, Product …

  • Check This BOOK #71202 #Kindle

    Scrum Essentials: Agile Software Development and Agile P…

  • Check This BOOK #71202 #Kindle

    How to Become a Scrum Master in 7 Simple Steps (Agile Pr…

  • Check This BOOK #71202 #Kindle

    The Scrum Checklist, For the Agile Scrum Master, Product…

  • RT @LifeWayTech: We’re heading to the Agile Nashville Meetup this Monday at noon. Are you? @AgileNashville #agile …
  • Interesting article on agile/scrum for physical product design. via @stratandbiz #operations @mulkdesign
  • FREE SCRUM EBOOK based on the AMAZON BESTSELLER: #scrum #agile inspired by #kschwaber
  • RT @rhundhausen: #Agile means getting rid of test teams. That’s what Microsoft did #scrum #proscrumdev
  • Are you thinking about getting a Scrum Master Certification? #agile #scrum
  • Read This Book #3342 #kindle

    Scrum Shortcuts without Cutting Corners: Agile Tactics, To…

  • Project Management with Kanban (Part 4) – Risk Review #agile #scrum
  • Categories: Blogs

    Why I Never Liked Scrum's Chicken and Pig Metaphor

    Powers of Two - Rob Myers - Thu, 09/04/2014 - 23:46
    A poem by Howard Nemerov:
    Bacon & Eggs The chicken contributes, But the pig gives his all. I've never been a user of Scrum's Chicken/Pig metaphor. It's a metaphor used by many Scrum coaches and trainers to provide a brief, humorous reminder that the team needs to be free to self-organize in order to accomplish their activities in an efficient and sustainable way.  Awesome goal.

    Just to be clear where I'm coming from today:
    • I get it.  A Certified Scrum Master once suggested that I don't understand the metaphor, and offered to elaborate. [I'm actually a little flattered whenever my opinion is interpreted as ignorance.] I'm not expressing ignorance, today, so save your keystrokes.
    • My feelings have not been hurt. [It's nice that folks worry about my feelings, too.]  Someone once suggested that if I was uncomfortable with this metaphor, I should simply stop using it.  [Commonly referred to as "blaming the victim."] I am expressing my opinion, of course, but I'm also conveying the feedback from dozens of behemoth corporations and popular little startups. [Heed my warnings, lest you be visited by three spirits...!]
     Here are a few of my reasons for avoiding it:
    • It's impolite:  A few key people in almost every organization I've coached have expressed their discomfort with folks referring to themselves or other people as farm animals.  To do so, even metaphorically, is often considered disrespectful, and unprofessional.
    • It's inaccurate: Many people who may not be directly responsible for creation and delivery may still have a critical stake in the success of the team (i.e., "skin in the game"), e.g., the Product Owner. Generalizing the Scrum roles in this way (as a divisive caste system) discourages people from dealing with other people in a genuine way. A coach needs to be careful to avoid subtly encouraging blatant disrespect towards leadership, or subtle disrespect for the team. A coach should be encouraging respect and professionalism at all levels.  We're usually there to repair the relationship between makers and leaders. The chicken/pig metaphor does little more (at best) than acknowledge the problem, and frequently (at worst) exacerbates existing bitterness.
    • It's limited: To me, the metaphor only make sense with regard to the daily "scrum" or stand-up meeting, and (in some cases, or so I've heard) the retrospective. "Pigs Only! No chickens!" It could be interpreted as discouraging collaboration with leadership.
    • It's old: It was Schwaber's clever metaphor about 20 years ago. Using it now would feel dogmatic, uncreative, and clumsy.
    Instead, we could ask: How does the team want to creatively communicate their need for autonomy, mastery, and purpose (The Pink Trifecta)?

    And if they all choose Scrum's Pigs and Chickens metaphor, so be it.  It is, after all, their restaurant.
    Categories: Blogs

    Welcome to the Swift Playground

    Xebia Blog - Thu, 09/04/2014 - 20:16

    Imagine... You're working in swift code and you need to explain something to a co-worker. Easiest would be to just explain it and show the code right. So you grab your trusty editor and type some markdown.

    let it = "be awesome"


    So now you have a file filled with content:

    But it would be better if it looked like:


    Well you can and it's super simple, all you need is some Markdown and:

    npm install -g swift-playground-builder

    After that it's a matter of running:



    More info:

    Categories: Companies

    What I’ve Been Readin, Writin, and Playin With - Thu, 09/04/2014 - 19:46

    I read constantly, but I’ve not reported lately on what I’ve been reading. These are things I’ve read, enjoyed, found valuable. I’ll mention some tools and toys as well. I’ll leave out things I hated. Isn’t that nice of me?


    Drive: The Surprising Truth About What Motivates Us, by Daniel Pink, has inspired a chapter in The Nature of Software Development, coming soon. He tells us that people are motivated by Purpose, Autonomy, and Mastery. This rings very true to me, and I hope it does to you.

    Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration, by Ed Catmull, tells the story of Pixar and how they maintain creativity in the face of relentless schedules and being part of a big business. I hope never again to be part of a big business, but Catmull’s stories of leadership are inspiring.

    Essentialism: The Disciplined Pursuit of Less by Ed McKeown, isn’t yet another book about simplifying your life. Well, it is, I suppose, but his approach to thinking about what really matters is valuable. I’m a sucker for thinking about myself, and if you are as well, you’ll find this book to be quite useful.

    The Man Who Knew Too Much: Alan Turing and the Invention of the Computer (Great Discoveries), by David Leavitt, is a very interesting story of Turing, his contributions, and the tragic end he came to. Fortunately, that last bit is mercifully brief and the story is quite interesting. It includes quite a lot about math and code-breaking but you can safely skip over those bits if you find them too heavy. Good story of an important figure in our profession.

    The Art Spirit, by Robert Henri, is a collection of writings about art. Henri holds that most anything we do well is art, and that art is the province of any human being. Very enjoyable.

    Joy, Inc.: How We Built a Workplace People Love, by Richard Sheridan, is the story of his company, Menlo Associates, and the thinking behind it. Quite idealistic, quite practical. Sheridan has built a very successful company with a focus on Joy. Definitely something to learn here.


    My fiction reading is all over the map. Science fiction, with forays into fantasy and steampunk. Adventure novels, spy novels. Once in a rare while, something like literature. Here’s a small sampling:

    The Iron Wyrm Affair, by Lilith Saintcrow, takes place in what seems to be Victorian London in an alternate universe. Emma Bannon is a sorceress in service of the spirit Britannia (and her avatar Queen Victrix), while Archibald Clare, her sometime work partner, is a “mentath”, a master of logic and deduction who rivals the great Holmes. Sounds pretty fluffy but this story and the following ones are strong, a bit dark, and quite enjoyable if you like the steampunk kind of thing. Saintcrow’s novels often please me. These are my faves of hers.

    Sniper’s Honor, by Stephen Hunter, is the ninth in his excellent series about Bob Lee Swagger, an aging retired sniper who gets into dangerous adventures, always involving snipers gone bad. The novels usually include a bit of history and are good spy/adventure stories.

    Permutation City: A Novel, by Greg Egan, is a hard SF story of people who load their personalities into computers for fun, research, and, ultimately to survive the death of the solar system. I think Bill Tozier (@vaguery) put me onto this one, and I enjoyed it.

    Another tip from Tozier was the Bel Dame Apocrypha series by Kameron Hurley, starting with God’s War: Bel Dame Apocrypha Volume 1. Is it set in some kind of a post-apocalyptic desert on Earth? On another planet? In a different universe? Fascinating, and it gets more so as the series goes along. Dark, and I think everyone dies — at least once.

    I would be remiss if I didn’t point out the work of Iain M Banks, who recently passed away. His “Culture” series, beginning with Consider Phlebas, is charming, funny, and deep. Truly great hard SF. Worth it for the names of the intelligent ships alone. Very highly recommended.

    Tools and Toys

    I guess I might as well show you some of the toys I’ve recently bought, for fun or profit. You may know that I’m trying to learn to draw, and my theory is that as soon as I get the right equipment, I’ll be able to do it.

    I have a fine Derwent pencil wrap for my ten thousand pencils, which come in all colors, textures, and permanence. This Derwent Canvas Carry-All Bag has room for those, my many erasers, and even a sketch book. And I can slip the iPad into it for those days when I can’t just be purely analog. The first one came without the included shoulder strap and Amazon sent me a new one by next day shipping.

    Laura Fisher, my webmistress (not as interesting as it sounds) told me about these Staedtler Watercolor Pencils. Since when I draw with Paper(tm), I often use the watercolor brush to color things, I thought I’d try these. You shade as you would with a pencil, then dab on a little water with a brush, and voila. Lots of fun and messy too.

    I also have an Parrot AR.Drone 2.0 Quadricopter, which is lots of fun. Parrot’s upcoming Bebop comes with a joystick controller, longer range etc etc. I thought it would be good to practice with joysticks, so I bought Syma X1, the little guy above, as well. So far, I am incredibly good at crashing it.

    Categories: Blogs

    Knowledge Sharing

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