Skip to content

Feed aggregator

Pumpkin Head Activity

Leading Agile - Mike Cottmeyer - Tue, 03/18/2014 - 16:58

halloween girl with pumpkin head

I have a nice learning activity to illustrate the benefits of product owners participating with teams. It is also about the team’s responsibility to make good use of the product owner’s time. It’s called the Pumpkin Head Activity.

You need a flip chart and a marker for each group. You need to download 3 simple pumpkin head stencils. Keep it simple. Here are some examples when I Google simple pumpkin head stencils. Order the stencils in order of complexity, simplest first.

Form groups of 4-6 participants. Read the following Activity Description to all of the participants.

Activity Description
  • The product owner will describe an image
  • The Team draws the image
  • PO never shows the image to the team
  • Team can ask questions
  • It may be an image of a pumpkin head :)
  • Run three rounds with a different image each time, about 10 minutes per round

Ask them to select a member to serve as product owner. Ask the product owners from each group to meet with you.

Product Owner Instruction
  • Give each the ordered drawings.
  • Repeat the instructions
  • Ask them to ensure the team does not see their drawing (use a workbook or folder so the other participants cannot see through the paper).
  • Ask them not to use their hands to describe the image or point to corrections (they can’t help themselves)
Instruction for each round
  • The Phone Call round
    • PO cannot look at the drawing. Have the product owner stand behind the easel or with their back to the drawing.
    • Debrief. Discuss why this is hard, unfair, nearly impossible.
  • Face to Face round
    • Product owner can look as the team draws. But product owners can’t use their hands.
    • Discuss the benefits of fast feedback. Can teams get too much feedback?
  • Accelerate Feedback round
    • Product owner describes an increment (the left eye for example) then waits. At least 3 members draw what they think they heard. The product owner picks the closest one and describes modifications, then waits. The team iterates.
    • Debrief. Discuss the benefits of incremental and iterative approach to accelerate feedback. Who is responsible for providing the opportunity to accelerate feedback?

This is frequently one of the groups favorite learning activities. Once the group has finished ask one more debrief questions. How did the team feel about accomplishing the drawing? How do the product owners feel? Teams can get very enthusiastic about accomplishing this task. Imagine if our work life was this exciting.

The post Pumpkin Head Activity appeared first on LeadingAgile.

Categories: Blogs

Back to the Basics: Coding and TDD

Learn more about our Scrum and Agile training sessions on

I’ve been working for the past year on building the Scrum Team Assessment (yes, you can still go get it for your team :-) ).  I’ve been doing all the work on it personally and it has been great fun.  The best part of it has been that I’m back into coding.  And, with that, of course I have had to take my own advice about Test-Driven Development and the other Agile Engineering Practices.  But it hasn’t been easy!

I’m using PHP for the web front end, and Python with OpenERP for the back end.  My testing tools include Selenium for Acceptance Testing and PHPUnit for unit testing.  And… nothing yet for the Python back-end.  This is still a sore point with me.  Normally, I would find the back end TDD process easier… but OpenERP has been a HORRIBLE BEAST to use as a development platform.  Well, I might exaggerate a bit on that, because it is really just the complete lack of well-written API documentation and sample code.  Which is funny, because there are tons of open-source extensions for OpenERP written.  Anyway, I don’t want to complain about it too much, because in many other ways it is a fantastic platform and I wouldn’t easily switch it for anything else at this point.

Back to testing.  Last week, a client using the Scrum Team Assessment found a bug… and it was one of those ones that I know made them consider not using the tool anymore. Fortunately, our contact there has the patience of a Redwood, and is helping us through the process of fixing the system.  How did the bug happen?

Because I didn’t do _enough_ TDD.  I skimped.  I took shortcuts.  I didn’t use it for every single line of code written.

<Failure Bow>

The question for me now, is “why”?  Fortunately, the answer is simple to find… but solving it is not as easy as I would like.  I didn’t follow my own advice because I was learning about too many things at the same time.  Here’s what I was learning all at once over a three week period in December when I was doing the real heads-down development work:

  1. PHP and PHPUnit
  2. Python
  3. OpenERP (APIs for persistence and business logic)
  4. RML (a report generation language)
  5. Amazon EC2, RDS and Route 53
  6. Some Ubuntu sys admin stuff
  7. VMWare Fusion and using VMs to create a dev environment
  8. Postgresql database migration
  9. Oh, and refreshing on Selenium

Like I said, FUN!  But, a bit overwhelming for someone who hasn’t done any significant development work since 2006-ish.  As well, because of learning about so many things, I also didn’t have a good setup for my development, testing and production environments.  Now I have to clean up.  Finally, I also forgot about another important Agile Engineering practice that is used when you have lots of intense learning: the Architectural Spike.

I have to make sure that I take all that I’ve learned and create a truly good dev and test environment (because that was a huge hinderance to my work with both Selenium and PHPUnit).  And I have to take the time to learn to do the testing in Python (I would love suggestions on a good unit test framework)… and go back over that code, even though most of it is simply declarative of data structures, and make sure it is well-covered by unit tests.  Ideally, I might even consider throwing some code away and starting from scratch.  One possibility I’ve considered is to get rid of PHP entirely and build the whole system with Python (I’d love some thoughts on that too!)

Why am I doing all this?  Well, I really think that the Scrum Team Assessment is an awesome tool for teams that maybe can’t afford a full-time coach.  It certainly isn’t a complete replacement, but I’ve poured my knowledge and experience into it in the hopes that it can help a bunch of people out there do Scrum better… and more importantly, create great teams that produce awesome business results and where people love to come to work every day.

Please share!
Categories: Blogs

Reassign JavaScript Function Parameters In Reverse Order, Or Lose Your Params

Derick Bailey - new ThoughtStream - Tue, 03/18/2014 - 14:00

Every now and then I need to have a method support 2 or 3 arguments, providing a default value for one of them if only 2 are specified. My typical solution is to check the number of arguments passed to the function and reassign the named parameters as needed. I think this is a fairly typical solution in JavaScript. Except I spent about 30 minutes trying to track down a bug, just now, and it’s somewhat perplexing to me.

Can You Spot The Bug?

Here’s a sample of the code in question, that you can run from NodeJS. I’m using NodeJS 0.10.26 in this case.

function foo(a, b, c){
  if (arguments.length === 2){
    a = "";
    b = arguments[0];
    c = arguments[1];

  console.log("a:", a);
  console.log("b:", b);
  console.log("c:", c);

foo("bar", "baz");

There isn’t anything terribly special here. Check the number of arguments. If it’s 2, then re-assign the ‘a’ variable to a default, reassign ‘b’ to what ‘a’ originally was, and reassign ‘c’ to what ‘b’ originally was. Note that I’m doing this reassignment through the use of the arguments array, as well.

Can you guess what the output is, based on the code above?



Why are my parameters empty?

How I Thought Parameters Worked

I’ve always assumed method parameters worked the same way as variables. If I have 2 variables pointing at the same data, and I reassign one of them, then the other one is not reassigned.

var a = "foo";
var b = a;
a = "baz";
console.log(a, b); //=> baz, foo

This makes sense to me. This is how by-reference variables have always worked in my mind. And so, I’ve always expected function parameters to work the same. But apparently method parameters don’t work this way. Based on the above behavior, my currently confused understanding of this relationship says that the “a” parameter is not actually a variable in JavaScript. Rather, it’s some special construct that references the value of arguments[0]… not a by-ref variable that points to this value, but more like a by-val variable that *IS* the value of this memory location. 

Given this by-val nature of the named parameter -> arguments[n] relationship, when my code above assigned “a” to an empty string it wiped out the “arguments[0]” value as well. 


Fixing The Bug: Reverse The Reassignment Order

In order to work around this, you have to reassign the parameters in reverse order. 

function foo(a, b, c){
  if (arguments.length === 2){
    c = arguments[1];
    b = arguments[0];
    a = "";

  console.log("a:", a);
  console.log("b:", b);
  console.log("c:", c);

foo("bar", "baz");

And now the results are what I expected:


By-Val Params

It turns out JavaScript does treat params and the arguments object as a by-val relationship. You change one, the other is also changed, unlike standard variables. From what I’ve read, this isn’t just NodeJS either – it’s the JavaScript spec.

Honestly, I had no idea that it was treating function parameters as by-val. After all these years with JavaScript, this language still surprises me.

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

Categories: Blogs

Your Code Sucks

TargetProcess - Edge of Chaos Blog - Tue, 03/18/2014 - 11:42

So you are sitting at your desk wondering how come your beautifully and carefully-thought out abstractions have turned into an ugly monster, and why your precious codebase smells like a giant mess? You may be not the smartest guy around but you are not that stupid or unqualified after all.

Well, just accept that your code sucks and stop worrying about it. Even the most brilliant programmers I know come up with the messy code or leaky abstractions sometimes. To fail is human. The business requirements come and go, the product evolves, you are growing as a professional. Don’t be OK with it, just stop torturing yourself trying to find the 100% perfect solution. If it works for now and it looks easy enough to be changed later, then it’s probably fine. On a side note, I would rather wonder why you are OK with any code at all. If you can’t spot an issue here or there then you are probably just not skilled enough to see the defects.

I’m not talking about some ‘forget the code, WE ARE SHIPPING THE PRODUCT HERE, B**TCH!’ management bull**t. The beautiful code and design is what makes your product easy to maintain and improve in the long run. The more skilled and experienced you become, the more likely you are to fall into the “disappointed in everything” mental trap. Try to think about it rationally – you’ve been around for quite some time, you’ve built some great stuff, your projects haven’t fallen apart as a consequence of awful technical decisions. And though your code sucks from your point of view, perhaps it’s not that bad on the absolute scale of code awesomeness.

What can we do make it less painful? Code review really helps a lot. Some developers complain about code review not being effective enough, i.e. it only helps you find the most basic formatting and code issues. I was a bit skeptical myself not so long time ago, but even if it helps to fix the formatting and minor code issues, then it’s a great improvement! I would say it’s a matter of trying and figuring it out for yourself. From my experience, early code reviews help to avoid possible design pitfalls, for example, if a developer hasn’t considered a specific use case of a module he is working on. What’s even more important is knowledge sharing. Two heads holding the feature implementation details are definitely better than one (you never know, this lonely developer working on some sophisticated data processing logic may get hit by an asteroid the next day).

Try and fail, learn from your experience. Reading books on code quality doesn’t help. Unless you’ve suffered from the f**ed up design or messed up code, you won’t understand why it’s important to think about future self supporting the codebase.

The code sucks. Repeating this statement makes no sense. What does matter is understanding why it sucks, accepting the trade-offs and constantly thinking about the ways to improve it.

Categories: Companies

Agile Requirements – the 3C’s

Growing Agile - Tue, 03/18/2014 - 09:00

I’m sure most of you have heard about the 3C’s before. This was first blogged about on 30 August 2001! That’s right – well over a decade ago. The reason why we still use it is because of its simplicity. 3 little things to consider and remember when crafting requirements. Its easy to get bogged down by details and solutions to problems. This is how giant requirement documents came to be. The true art is in the conversations that take place around a requirement.

blog 3c Agile Requirements   the 3Cs

Card – This refers to index cards which are usually used to write down requirements. Even if you are using a tool, what is important is that the card is just a ‘reminder of a conversation’ that needs to take place. It is useful to contrast it to a detailed requirements specification. Clearly everything you need to know cannot be contained on a single index card.

Conversation – If the details aren’t on the card, then people wonder where they will get them. This is where conversation fits in. Agile requirements are understood through conversations. If possible face-to-face conversations, with the entire team. This way people can ask questions, clarify understanding, suggest changes, etc. Often people with traditional project experience are used to reading documents and only then asking questions. This is not the same. This is the conversation before anything is written down, this conversation helps to form the requirement. If people find requirements documentation helpful, we suggest they decide what needs to be written down during the conversations.

Confirmation – The confirmation is how everyone will know that the requirement has been met. It is usually statement in the form of an acceptance test, essentially what a user would do in the system and what they would expect to happen once this requirement is done. Traditionally acceptance tests were written on the back of the index card. If people don’t know what to write here: ask “how will you know when it’s working”?

Additional Reading:

book4 Agile Requirements   the 3Cs

In our book “Growing Agile: A Coach’s Guide to Agile Requirements” we have a workshop you can run with your team to help them learn about this topic.

Categories: Companies

Die Ypsiloner

Scrum 4 You - Tue, 03/18/2014 - 08:54

Den passenden Job zu finden ist offensichtlich genauso schwer wie den passenden Mitarbeiter auszuwählen. Man sollte meinen, die Recruiter hätten die „Qual der Wahl“ vor lauter Arbeitsuchenden klugen Köpfen da draußen. Dem ist aber nicht so. Also nicht, dass es keine klugen Köpfe gäbe – es herrscht wohl eher eine Inkompatibilität mit den vorhandenen Arbeitsplätzen.

Junge Absolventen haben offensichtlich das Interesse an klassisch geführten Unternehmen verloren. Sie haben keine Lust auf Hierarchien und die damit verbundenen politischen Machtspielchen. Heutzutage möchte man lieber die Welt verändern und einem sinnvollen Beruf nachgehen, anstatt den Business Value eines Unternehmens zu erhöhen. Manch Personaler schüttelt den Kopf über diese “verträumte” Einstellung. Man kann doch nicht den gesamten Arbeitsmarkt auf den Kopf stellen, nur wegen dieser heranrückenden Generation Y, die offensichtlich noch nie den Ernst des Lebens gespürt hat! Die Generation, die nach 1980 geboren wurde, und alles hinterfragt – den Vorgesetzten, den Sinn der Arbeit und die Ziele der gesamten Organisation.

Gerade in Unternehmen, in denen agil gearbeitet wird, haben wir es mit vielen solchen “Ypsilonern” zu tun. Junge ScrumMaster, die ihren Vorgesetzten auf Augenhöhe begegnen, Themen eigenverantwortlich vorantreiben, Impediments lösen und langsam ihr ganzes Umfeld verändern wollen. Allerdings stoßen sie mit diesem Verhalten auch schnell an die Grenzen der Organisation. Zum Beispiel an Teamleiter, die ihre Position verteidigen und sich von den, als hierarchisch niedriger eingestuften ScrumMastern, nichts sagen lassen. Starre Strukturen, die sich auch mit viel Elan und Ausdauer nicht brechen lassen. In einem solchen Umfeld resignieren ScrumMaster häufig – und kündigen früher oder später.

In diesem Falle stehen die Recruiter wieder vor der herausfordernden Aufgabe, die offene Stelle passend zu besetzen. Doch wie anfangs erwähnt, ist das gar nicht so einfach, eher zermürbend. Vielversprechende Bewerber werden letztendlich doch wieder mit den hartnäckigen Strukturen einer hierarchischen Organisation kämpfen müssen. Entweder sie ordnen sich dieser unter, oder sie gehen. Im Falle der Generation Y wird es die letztere Option sein.

Klar kann man diesen Trend auch als solchen abtun und weitermachen wie bisher. Allerdings werden dieselben Leute, die heute als Absolventen von den Unis gehen, eines Tages das Sagen im Unternehmen haben und ihre Einstellungen werden die Arbeitswelt auf Dauer prägen. Eigentlich ist der Zug schon ins Rollen gekommen. Entweder man springt auf und ändert die alten Muster, oder man bleibt auf der Strecke und schaut, wie weit man kommt. So oder so brechen spannende Zeiten über uns herein.

Related posts:

  1. Mr. M auf bor!sgloger – Das Unternehmen
  2. Management 3.0
  3. Von “verscrumpelt” zu “verscrummed”: Agilen Frust iterativ beseitigen

Categories: Blogs

Scope Creep. It’s What’s for Dinner.

Agile Management Blog - VersionOne - Mon, 03/17/2014 - 22:27

Once upon a time there was a whiny Product Owner, two Team Leads, a Dev Director, an executive, and only 2 days to go in the sprint.

Enter the unplanned feature. The villainous Scope Creep we all know and hate.

But he pays our bills so we stay here late at night. And take it like a champ.

Can you guess what happens?

Watch more Prevent Agile Pandamonium videos like this

Categories: Companies

Half-Life of commitments

Agile Tips - Mon, 03/17/2014 - 19:36
Half-life is the amount of time required for a quantity to fall to half its value as measured at the beginning of the time period. 

During private PSF (Profession Scrum Foundation) classes my students create a Change Backlog. The idea of this backlog is to codify the things that need to be changed in order to become agile. Actually, after they finished creating the backlog I ask them to put a name on each sticky note, meaning that the person whose name is on the note is responsible for acting on that item and is accountable for it. Finally, I ask them right away to define a date at which they will review this backlog. Inspect and Adapt.
I am doing this to avoid the training conundrum ‘Yeah, this has all been very interesting but right now I don’t have the time and right situation at hand …'
In my opinion if you don’t go out immediately after the training and walk the talk, your motivation will decrease rather dramatically. Not that I have researched, but my feeling tells me that the half-life is about one week. So, after two weeks your motivation is down to a quarter.
Also, I see best results when whole teams get a company private class. Even better when their superiors join in too, if not for the entire training but for the last 3 hours of the second day when we create the Change Backlog. This exercise creates a transparency which hardly can be reproduced in a later setting. At the end of day two, most of my students are really enthusiastic to get started and the managers sense this as well. 
High chances of success: An enthusiastic team with management support: you are ready to roll on your path to agility.
Categories: Blogs

Mind the WIP to Become Effective, Not Merely Efficient

BigVisible Solutions :: An Agile Company - Mon, 03/17/2014 - 19:26

Mind the WIP to Become Effective, Not Merely Efficient

“Efficiency is doing things right, while effectiveness is doing the right things.”

We’d all like to be efficient.  We’d love to show our boss how cheaply we can get something done, compared to all her other options.  We’d like to have extra time, maybe to clean up, beautify, or just goof around.  Efficiency is the hallmark of mass manufacturing.  If we build it for less, we have more profit to put in our pocket.  But did you ever consider that when we build software in situations where resources and dates are fixed that you’re making a huge, risky bet?  I venture to say that you’d rather ship 80% of your product features on a certain date (and have least valuable 20% left over for “the next time around”) than be 90% done on everything and have absolutely nothing to ship on that due date.

You probably have 2 questions at this point.  “How could that be?” and “How can I be effective, and not merely efficient?”  The answer to both questions is found in three tiny letters – WIP (work in process).

It all begins with estimation

Let’s take an easy example for this piece.  Here’s a list of things that we’d like to develop some software for and release to our new website in the next 90 days:

  • Allow website users to search for and display lists of items in our warehouse
  • Give website users the ability to display pictures and details for an item that they select
  • Give website users the power to display real time inventory status for an item that they are looking at
  • Give website users the ability to create a “shopping cart” of quantities of items that they select
  • Allow website users to complete a transaction and pay with credit card(s), PayPal, direct checking account, or any combination thereof

Assume that since we only have 90 days, the Delivery Team that we have, is the army that we will use. The 90-day window is non-negotiable, because we paid a zillion dollars for a Super Bowl ad that will drive traffic to our website on that fateful day.

If you’re a traditional, plan-driven project manager sort of person, you probably do this project by first decomposing the software stack into components that we’ll put together, and then create a project plan that pulls people, time, and dependencies together and convinces us that everything will be fine.

  • Database for the warehouse items
  • Component to access database
  • Website functionality for search
  • Website functionality for display
  • Website functionality for real time inventory
  • Website functionality for adding, displaying, deleting, and modifying items in the shopping cart
  • Component for integrating our warehouse system with the website real time inventory status
  • Component for implementing the shopping cart on the server
  • Component for credit card processing
  • Component for PayPal processing
  • Component for checking account ACH processing
  • Component for payment coordination between the various processing options

OK.  Got the list.  Get some estimates from various people.  Assign developers against the tasks.  Adjust estimates to make everything fit inside that 90 day window (Tell me that you’ve never done this.  Be honest!).  Announce “It’s going to be tight, but the plan demonstrates that we can do this.  So, let’s get going!”

With software, the odds of everything working in your project plan are a lot like your odds of hitting the Trifecta

But here’s the rub.  Estimates are made for things that we haven’t previously done.  We use our best effort to understand and give meaningful honest estimates.  And we do.  But the uncomfortable truth is that effort-based estimation for software construction is highly variable, due to a variety of factors:

  • Uncertainties with how to do things that we’ve never previously done.  For example, we’ve never tried to interface with our mainframe based warehouse system before.  We may find little nooks and crannies of problems and issues which we must solve to permit the integration that we never considered when we gave our limited “happy path” estimate.
  • Uncertainties around what things we should actually build.  For example, should that real-time warehouse inventory level stop people from adding items into their cart? Stop them from completing a transaction? Or just ask them if they want to place the item on backorder?  We’ve never done this with customers before, and we can’t be sure that customers will bring us enough value to cover our costs of development, since we’ve never before given customers this ability.  If we have to re-do a lot of work for a fully fleshed out feature, that could cost a lot.
  • Uncertainties based on who actually does the work.  Your best developers may be 10 times (or more) productive than your least capable ones.

And then we completely hide that variability in estimates by expressing a single number for the estimate.  The estimate, even though it is expressed as a single number, is really a probability curve.  It might look something like this:

Graph Source

And, finally, we completely compound and confound the problem by linking the tasks together with scheduling dependencies.  “We can’t start/finish this task before finishing/starting that one” (either because of software functionality dependencies or resource dependencies). Our project is a hope, wish, and desire that everything goes according to plan, even though we mathematically know that things will go wrong, and will start to cascade through the chain of scheduling dependencies.  If we start creating the compounded probability of arrogated estimates, we start to see that the nice peak on our bell style estimate distribution curve starts becoming very short and wide.  And our chances of hitting our estimate square on are about as likely as picking the “win, place, and show” horses, in order, at the track.

Yet somehow, seeing everything fit together in a nice Gantt chart that magically ends right on target makes us feel safe and sound.  At least when we start.  But without fail, almost every project plan that I’ve been around goes sour quickly.  One late dependency quickly snowballs into an avalanche of late tasks that just compound and worsen. Blame starts getting metered out.  Morale goes through the floor, and when we’re living the day before the game, we try to integrate everything, and nothing is working.  And now that the business sees the real time inventory status in action (when it sort of works) they aren’t sure that they want it, as they now realize that when people see that an item won’t be in stock for a couple of weeks, they may decide to go elsewhere!  But we’re so afraid that pulling out the code will break 20 things against the middle.  So, it’s part of the deployment, like it or not.

Gantt Chart

Our attempt to be hyper-efficient and get each and every feature working the day before the end suddenly becomes an #EPICFAIL when things don’t work on Super Bowl Sunday.

That’s horrible!  What’s a Mother to do? 

What if we turned this on its head?  Let’s say we start with a single ranked ordered list something like this?

  1. As a website user, I want to search for items to purchase using words in an item’s description, so I can find things to buy.
  2. As a website user, I want to display an item’s description, price, and primary picture, so I can decide if I want to purchase it.
  3. As a website user, when I click the “Buy It Now!” button on an item’s display page, I want a quantity of one item placed in my shopping cart so I can purchase it when I’m done shopping.
  4. As a website user, when I click the “Proceed to Checkout” button, I want my shopping cart displayed with checkout options.
  5. As a website user, when I click the “Purchase Now!” button with the “Debit My Checking Account” option clicked, I want an ACH setup to my checking account for the amount due and the items in my cart shipped to me, so I can become a happy and loyal customer.  Note: this transaction is free through our bank.  Yay!
  6. As a website user, when I click the “Purchase Now!” button with the “PayPal” option clicked, I want my PayPal account to be debited for the amount due and the items in my cart shipped to me, so I can become a happy and loyal customer.  Note: we pay a 1% merchant fee on PayPal transactions.
  7. As a website user, when I click the “Purchase Now!” button with the “Mastercard” option clicked, I want my Mastercard account to be charged for the amount due and the items in my cart shipped to me, so I can become a happy and loyal customer.  Note: we pay a 2% merchant fee on Mastercard transactions.
  8. As a website user, when I click the “Purchase Now!” button with the “American Express” option clicked, I want my American Express account to be charged for the amount due and the items in my cart shipped to me, so I can become a happy and loyal customer.  Note: we pay a 4% merchant fee on Mastercard transactions.
  9. As a website user, when I want to be able to change quantities and delete items in my shopping cart when I am checking out so I don’t get frustrated with a shopping cart that is not exactly what I want to purchase.
  10. As a website user, I want to display an item’s auxiliary pictures, to help push me to clip the “Buy It!” button.
  11. As a website user, I want to display an item’s real time inventory status, to help me decide if I want to buy the item now.  Note: the website user may decide to not buy the item when they see that it’s not in stock.
  12. As a website user, when I click the “Purchase Now!” button with the “Multiple Credit Card” options clicked, I want the ability to setup a complicated transaction [details to be thought through], so I can become a happy and loyal customer.  Note: we have to figure out technically what happens here, how to back out of scenario such as having one card going through and a subsequent card failing.
  13. As a website user, I want to backorder an item that real time inventory shows as out of stock so I can eventually purchase the item.  Making this happen will invoke a workflow involving eMails, order cancellation, and other things.

Notice what happens when we start to develop one thing at a time, in this order, and get feedback from the business as we complete each of these items.  If we got some of the details wrong (it happens all the time!), we can immediately get that right before we move on.  When the business says “Good!” on each item, we then get our deployment to stay “always ready to ship”.  If we run out of time, we may not have every feature completed, but we always have something to show on Super Bowl Sunday.  We’d like to get through the whole list, but we don’t even really know the details for some of this yet.  But we have enough to get started.

Untitled 2

What was different?

That’s easy.  We minded the WIP.

We made sure that we had the highest value items worked first, and did one thing at a time (“Single Stream Flow”, in Lean terms).  We were always ready to ship.  That allowed us to work right up to game time without fear that integration would ruin things.  We didn’t have to worry that we wouldn’t get to go home for the next two days, subsisting purely on Mountain Dew and day old pizza.  We concentrated on delivering value one step at a time, from most important to the least.

That pivot to focusing on business value, rather than figuring out the optimal plan that gets us to done can be a huge mindset change for some organizations.  Sometimes, managers are afraid that someone won’t have something to do when the team is working through the business value ordered backlog of functionality to create.  But remember, every time we add to our WIP, we create the potential that dependencies will keep us from being ready to ship.  We create the potential to very efficiently work on lots of stuff at once, but have nothing to show for it when the clock runs out. That’s not very smart.  And it’s awfully risky. It sure isn’t an effective way for your organization to work.

The prime directive is effectiveness – efficiency is only secondary

I don’t know how it works for your business, but for mine, I’d rather deliver 80% of the highest business valued items and leave the remaining 20% of lowest value items for sometime in the future.  I really don’t want to be 90% done with everything, but having nothing to show for it when the clock runs out, because that last 10% was needed to get anything to work.

For me, Meatloaf said it best, almost 40 years ago.  “I want you, oh, I need you.  But there ain’t no way I’m ever gonna love you. Now don’t be sad, oh, ’cause two out of three ain’t bad.”

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



The post Mind the WIP to Become Effective, Not Merely Efficient appeared first on BigVisible Solutions.

Categories: Companies

Load Impact Releases Plug-in for TeamCity Continuous Integration Server - Mon, 03/17/2014 - 19:03
Load Impact today announced the immediate availability of a plug-in for TeamCity that allows users of the popular Java-based build management and continuous integration server to run automated tests on the performance of their software.
Categories: Communities

It’s MAD to Have a Separate Discovery Phase

Constant Change - Aaron Sanders - Mon, 03/17/2014 - 16:15

Here we are with another Misadventure in Agile Discovery (MAD). This one pairs well with the first misadventure, the separate discovery team. Even when that mistake is corrected and a balanced team is working together through discovery and delivery, the team may decide to spend some time furiously creating a slew of new ideas. After […]

The post It’s MAD to Have a Separate Discovery Phase appeared first on Constantly Changing.

Categories: Blogs

Updated: Agile Estimation with the Bucket System

Learn more about our Scrum and Agile training sessions on

I have added a pdf download of this article about Agile Estimation with the Bucket System.  It’s just a handy, nicely-formatted document that can be used for quick reference.  It is now part of the materials I give out for my Certified ScrumMaster training classes.

Please share!
Categories: Blogs

Top 10 Negative Personas of a Daily Standup Meeting

Leading Agile - Mike Cottmeyer - Mon, 03/17/2014 - 14:49

Standup Meeting

Agile teams should be holding a daily standup meeting.  Don’t think of it as a daily planning meeting. Think of it as a daily opportunity to have a shared understanding of what is getting done and what lies ahead.  During a daily standup meeting, participants sometimes exhibit negative personas that will detract from the meeting.  As an empowered team, it is your job to self-manage and encourage good behavior. Some of these behaviors are so common, we don’t even realize people are doing them. So, I’m giving them some names. Next time you hold a daily standup, see if anyone exhibits any of these 10 behaviors. If you think of some behaviors  that should be added to the list, I would love to see them.

Daily Standup Meeting Negative Personas


10. Pat Decker the Obsessive Phone Checker

This person does not always pay attention and is constantly look at her (or his) phone. Did a BFF just like something? Did someone on Twitter just favorite that pic of the team board? In addition to checking her phone, she likes to share what she sees with others during the standup. “Pssst, Bob, check out this Vine video or pic on Instagram”. She’s not so loud that she’s overly disruptive but now Bob missed what someone else said during the standup.

9. Stephen Craig who is Always Too Vague 

This person can get stuck on the same task for days but doesn’t want anyone to know. When speaking to the team, they are crazy vague. Stephen will offer very few details until the team pushes for a deadline. He (or she) will use language like “Yesterday I was working on task 123 and today I will be working on it some more”. No other information is volunteered. When asked if they need any help, they clarify they have no blockers or risks.

8. Bobbie Bainer the Team Complainer

When the attention is on Bobbie, get ready for the positive energy to be sucked right out of the room. Bobbie complains, complains, and complains some more. Management, teammates, or the technology is all fare game. Everything and everyone sucks and no one knows just how bad they have it. Don’t bring up religion or politics unless you want Bobbie to go right into a 20 minute tirade.

7. Jess Jewler who loves the Water Cooler

Jess comes to the daily standup to talk, but not about what needs to be done today. Instead, he or she will talk about just about everything else. The next 15 minutes is dedicated to the water cooler. Did you see the last episode of House of Cards or The Walking Dead?  Are you going to watch the Ravens play this weekend?  My son plays Minecraft and constructed this totally awesome building with redstone. Anything is fair game, as long as it’s not about work.

6. Billy Platitude with the Bad Attitude

Billy is a leftover from a bygone era. He was the best of the best mainframe developers and all he needs is a DLD and he’ll give you what you need… in a few months. You want any changes between now and then? Forget it!  He thinks all things agile are stupid and just plays along begrudgingly. You may catch him make cynical “funny” comments at standup to point out how right he is about how stupid agile is.

5. Will Funky the Non-Committal Junkie

Will does not want to be painted into a corner. Typically, he uses language like try, maybe, pretty sure, I’ll get back to you, we’ll see, would like to think, soon, almost. You’ll also see Will be the last person to comment on something and will usually go with the crowd.

4. Tom Mater the Specialty Updater

Tom only gives vague commitments, usually understandable only by those in his discipline. The overall team gains little value from the statements. If you ask him for details, he’ll either tell you to look it up in a tool or he’ll be very technical in his response. Half of the team doesn’t understand what the hell he’s talking about.

3. Drue Gru who thinks he’s Better Than You (and the team)

Drue has been around for a long time. He’s better than you and he knows it.  If you need him, you know where to find him. He either arrives to the standup meeting late or he doesn’t come at all.  He has little to say because you wouldn’t understand what he’s talking about. He already knows everything so what is he to gain by slumming with you and the team for 15 minutes? Let him know when something important happens. *sarcasm*

2. Pearl Revolver the Problem Solver

Pearl means well but she lacks a sense of time. She wants to have in-depth problem solving discussions on obstacles identified during the standup meeting. She’s very curious what issues others are having because she’s going to want to talk it out and fix it right then and there. Even if there is a reserved 15 minutes after the standup, Pearl figures there is no better time than the present to tackle a challenge.

1. Ian Krumpter the Interrupter

Do you listen or do you wait to talk?  Stop and think about that. There is a difference. Ian waits to talk. People can be binary in that way. If you’re talking, you’re less likely to be listening. He wants to prove just how awesome he is so you’ll see him interrupt even if the topic doesn’t really apply to him.

The post Top 10 Negative Personas of a Daily Standup Meeting appeared first on LeadingAgile.

Categories: Blogs

Die Kraft der Begeisterung

Scrum 4 You - Mon, 03/17/2014 - 08:30

Vor ein paar Tagen erlebte ich (endlich) einmal wieder so einen Moment … einen Moment, der mich wissen lässt, dass es nicht reiner Idealismus ist zu glauben, dass Menschen Spaß an ihrer Arbeit haben und aus ihr Energie ziehen können.

Einen Moment des Leuchtens in den Augen, der Begeisterung, des Mutes, des Gestaltungswillens! Der PO – der mit dem Leuchten in den Augen – war in ein Projekt reingeraten, bei dem politische Zwänge, künstliche System- und Entwicklungstrennungen und vermehrte Absicherungsaktivitäten das Arbeiten alles andere als agil machten. Vorherige Anläufe waren bereits gescheitert bzw. die Live-Stellung war schon einige Male verschoben worden. Zur Absicherung der eigenen Abteilung ließ man höchste Vorsicht walten in der Zusammenarbeit. Man bestand auf lupenreine Schnittstellendefinitionen im Vorfeld, Abnahmen ohne Anbindung des Systems an die Schnittstelle bzw. das Frontend, parallele Abarbeitung unterschiedlicher Anforderungen und und und …  Zwar wurde in 2-Wochen-Sprints gearbeitet, doch die Resultate waren für niemanden wirklich zufriedenstellend. Man hatte sich allerdings irgendwie damit abgefunden, vielleicht gerade aufgrund der Projekthistorie.

Aufgrund einer unabhängigen Anfrage des Fachbereichs/Kunden zur Umsetzbarkeit einer Funktionalität im System wurde sich der PO aber wieder darüber bewusst, was sein System eigentlich drauf hatte. Aufgrund dieses Impulses traute man sich plötzlich, das vermeintlich Offensichtliche zu denken: “Können wir nicht die Funktionalitäten, die der Kunde sich seit Jahren durch die Einführung eines neuen Systems erhofft hat, nicht auch viel einfacher im eigenen System abbilden?”

Als der PO diesen Gedanken aussprach, erinnerte er sich daran, dass er genau dies als Vision für sein neugegründetes Team vor einem Jahr formuliert hatte. Und auch damals schon war plötzlich eine Energie und Klarheit im Raum, wie sie keine schriftliche Dokumentation und Absicherung jemals erzeugen kann. Sie war positiv! Damals wie heute bei der gleichen Sache.

Diese positive Energie zeigte mir als ScrumMaster, in welche Richtung ich weiterarbeiten musste.

Related posts:

  1. Design of a complex system – Tom DeMarco
  2. Is educaton killing creativity?
  3. Design eines großen Systems – Tom DeMarco

Categories: Blogs

Waterfall Is Never the Right Approach

NetObjectives - Sun, 03/16/2014 - 04:22
As a side note, this blog was inspired by a response to my discussion on the Scaled Agile Framework linked in group called Challenging the assumption that one must get teams to work first, before going to scale (which I recreated as the blog prior to this). I often hear that there are cases where waterfall is best.  I don't agree. I actually don't believe adopting waterfall as an approach is...

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

Challenging the Assumption That One Must Get Teams to Work First

NetObjectives - Sun, 03/16/2014 - 04:08
I wrote this entry as the start of a discussion on the Scale Agile Framework linked in group by the same name.  You can see that thread here. Here's the post, that I realize makes a good blog: As some of you may have seen, Ron Jeffries put forth a blog on SAFe that assumes something I don't agree with: Always get teams doing Agile before starting to scale. As Ron puts it "most of your teams...

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

Music and Wellbeing - Nikki Rickard

Notes from Nikki Rickard's session at the 4th Australian Positive Psychology and Well-being Conference:
What causes musical pleasure?
  • Faster tempo
  • Major modes
  • Bright timbres
  • Consonant intervals
  • Regular rhythms
What are the mechanisms?
  • Imagery: sounds like pleasant things
  • Entrainment: coupled to an internal rhythm (e.g., hear rate, movement, etc.)
  • Contagion: mimics perceived emotion
  • Arousal: felt in the body
  • Expectancy: prediction and schema
Beyond the music
  • Performance, that is the skills of the performer
  • Context
    • Location
    • Event type
    • Audience behaviour
  • Listener

Categories: Blogs

Time Out for Adults

Portia Tung - Selfish Programming - Sat, 03/15/2014 - 22:00
Light of Mind The State of Play

Every so often, people come to me for advice. “How are you?” I ask. “Life is good. Lots going on. Plenty to do,” says my friend. Then just before her voice trails off, “Perhaps too much.”

In our frantic world of go-getting and Blackberry prayers at the dinner table, there can be little time to catch our breath, let alone think. And think clearly.

The Value of an Empty Mind

The most effective thing I’ve learned to do is to take time out. That’s easier said than done, of course. The trick is to first recognise when your head is full. Then you look out for the next moment when you find yourself sitting still in a quiet spot. You then seize the moment and empty your mind.

Staring out the window is a great way to decompress quickly. Notice all the minutiae your eyes usually gloss over, like that robin staring straight back at you through the window. Or pay special attention to the sounds around you. If you listen carefully, you may even hear Nature’s symphony of spring.

“How long do I need to sit for?” you ask. “I’ve got stuff to be getting on with.”

Mindful Thinking

Taking a moment to pause for breath helps empty my mind. I know I’ve paused for long enough when the curtains of the empty stage that is my mind begins to twitch and fresh ideas skip in, gently reminding me of why I rush around so much. Of how I’d like to live my life.

Time out isn’t just something that can help our children pause for thought. When we’re able to take ourselves to the time out place as adults is when we’re able to become whole again.

Categories: Blogs

Design Your Agile Project, Part 3

Johanna Rothman - Sat, 03/15/2014 - 20:52

What do you do  for geographically distributed teams, if you want to move to agile?

First question: does the team want to move to agile? Or, does the management want to move to agile? I am serious.

I might take the same actions, but for different different reasons. In either case, the team needs to learn about what agile and lean means, and how to do agile. In both cases, the team needs help and protection from management.

Why Does a Geographically Distributed Team Need Help and Protection from Management? Types of Teams

Types of Teams

Managers create geographically distributed teams for many reasons. Some reasons are that there are smart people all over the world. In that case, managers create feature teams.

When managers create dispersed teams, teams with one and two people in disparate locations in far-flung locations (more than 60 meters away), managers are under the impression that “experts” can perform jobs better than teams can.

When managers think that “experts” can perform jobs better, they create bottlenecks in the work. Bottlenecks prevent flow. Bottlenecks prevent agile or lean from working. It does not matter if you want agile or lean. You won’t get either with a bottleneck. You have to overcome the bottleneck.

Can you make a geographically distributed team work in an agile way? Yes. Let’s go back to the principles.

Our principles of agile or lean:
  1. You need to see all the work in progress.
  2. You want to flow work through the entire team.
  3. You want to see working software, sooner, rather than later.

If you, like me, don’t care how we get there, we have options.

How Could a Team Take These Principles and Create Their Own Agile Approach?

Let’s take one thing at a time.

Let’s assume the team is not accustomed to working on small items of value. If you are like many of my clients, this is the case. What would it take for the team to start working on small features that deliver value?

Let’s think about the product again:

Potential Release Frequency

Potential for Release Frequency

What kind of potential for release frequency does the team have? That colors the team’s thinking. The more potential for continuous deployment, the easier it is to work on small items of value.

This is where I like to introduce the notion of spikes and timeboxes. I ask the team to take their smallest feature, and work together on it. They don’t always have any notion of “together,” either. They say things such as, “We need …” and list the impediments to their ability to work together.

Now we see the need for management support.

Project Management is Not a Dirty Word; Neither is Management

I know that some of you dislike the idea of agile project managers. I know some of you positively hate the idea of management in agile organizations. Let me suggest that for teams transitioning to agile, there is a place for management. That place is creating an environment in which the team learns how to self-manage.

There is no place for command-and-control project managers—never has been, never will be. Unless it’s time for lunch. Sometimes, teams need people to say, “Lunch-time!” But even that isn’t command-and-control. That’s someone saying, “I’m taking care of my need to eat. Want to come along?”

It’s the same thing for a team with a lot of risk and a lot of unknowns. A team where the normal, out-of-the-box agile solutions don’t work. Why would you let a team like that flounder?

That team needs everyone to lead. And, it often, but not always, needs someone to represent that team to management. Why? Because management doesn’t understand agile yet. That part might come now, and it might come later. But in an agile transition with many unknowns, it almost never happens at the beginning, even if management is saying, “Please go agile.”

A geographically distributed team needs management support. It does not need command-and-control. That team does need support.

That’s when I ask the person working as the project manager to start removing impediments. The team creates their own visual board. (Yes, a distributed team almost always needs a tool. I like to start with cards on a wall first, take pictures of it. Once a team knows how they like to work, then they choose a tool.) The team decides what the length of their timebox is for this feature, if they want to use iterations. They decide how to spike it. They start making decisions.

That team especially needs to understand the problem of bottlenecks, experts, and how to stop needing experts.

After they practice this a couple of times, they have the confidence they need to do this more times on their project. They can call this agile, but it might not have a real name. It’s a mishmash of timeboxes and kanban, but it works for them. Does it matter what it’s called?

The Team Needs Management to Remove Obstacles

Teams might need management support. For example, I often discover geographically distributed teams don’t have enough testers. Well, you say, that team flunks the “we have all the cross-functional roles to do the work” part of agile. Yes, and what if they don’t know that? What if they want to try agile? What if they want to work through their obstacles and impediments? They need someone to represent them to their management, while they try to test as they proceed, right?

You could substitute “database admin” or “GUI designer” or whatever it is you need for tester in the above paragraph. Whenever you need someone to advocate on behalf of the team to management, you might want an agile project manager. Not someone to say, “When is the project going to be done?” Nope, not that kind of a PM. Someone to say, “What does the team need? I can help acquire that.”

PMs who provide servant leadership to the team, and represent what the team has accomplished to the rest of management can be invaluable. They can help the team understand its process and facilitate what the team can do if the team gets stuck. These are agile project management skills.

At this point, the team can try several approaches I suggested in these posts:

You might have an even better alternative than the ones I suggested.

Do you need a project manager? No. Do you need a servant leader? In my experience, yes. Maybe in your experience, no. I would love to hear from you, if you have a geographically distributed team that does not have a servant leader.

How Does This Team Evolve?

CynefinSome of my clients who are committed to agile have evolved their dispersed teams to be feature teams in multiple places. That has worked very well for them.

That has allowed each team to transition from the Complex to the Complicated. They now have collocated agile or lean teams. They can design their agile projects, as in Part 1. They retain the value of smart people all over the world. They don’t have the aggravation of trying to meet in different time zones for a project. They still have it for the program.

Some of my clients are still trying to make the dispersed teams work. It’s really hard. You might want to read my paper about the common problems on these teams.

Where are we now?

In Design Your Agile Project, Part 1, we discussed a straight-on approach to using whatever approach to agile, because it was obvious where you were.

In Design Your Agile Project, Part 2, we discussed looking at your system of work, and thinking about your unknowns. You need to think about your risks, and consider what you need to experiment with, to design your own agile project.

This part, part 3, is a continuation of part 2. It matters because you might need a servant leader who might be called a project manager. The title matters, because especially on a geographically distributed team, you are bridging the gap and the culture between the old way of working and the new way of working. I still think it’s Complex. Some of my clients think it’s Chaotic because they have so many impediments.

Whatever it is, you need data to take your next step.

Categories: Blogs

Public Impediments – Charlotte March 2014

Agile & Business - Joseph Little - Sat, 03/15/2014 - 00:48

The group came up with these impediments.

  1. People issues
  2. Distractions (multitasking)
  3. Lack of resources
  4. Arbitrary long time estimates
  5. Lack of feedback
  6. Black box projects
  7. Dishonesty
  8. Management constraints
  9. Team too big or too small
  10. No clear roles
  11. No funding
  12. Unrealistic expectations, time or $
  13. Team improperly formed
  14. Too many impediments (main cause of failure)
  15. Inexperience (wrong skills)
  16. EGO
  17. Poor listening
  18. Unchesiveness
  19. (lack of) localization support
  20. No direction
  21. Stubborn people not aligned with Team
  22. Budgeting not clear
  23. Shareholders having diverse interests
  24. Lack leadership
  25. Teams not talking to associated teams
  26. Lack of resources dedicated to Team
  27. People turnover
  28. Performance not measured – no data
  29. Real product owner is not identified
  30. No clear process / product owner
  31. Cross-purposed stakeholders
  32. Lack of stakeholder buy-in / support
  33. Upstream / downstream dependencies

We hope this list helps your team get more creative about the impediments.

We are a strong advocate of a public impediment list.


Categories: Blogs

Knowledge Sharing

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