Skip to content

Feed aggregator

Hunting for The Elusive Swarming Rule

Agile Tools - Sat, 09/20/2014 - 07:58


There are a variety of different ways of going about swarming. There is the ad hoc approach: all hands on deck, everybody find a way to help. Then there are methods are a bit more subtle. You aren’t just dog piling on whatever the problem is. Instead, what you are doing is applying simple rules that allow behavior to emerge. Easy, right?

Not really. The trick is learning what those rules might be. We are looking for simple rules that when followed may reveal emergent patterns that are hard to predict. That very emergent nature makes them hard to discover. You can’t just say, “Hey, I want a simple rule to build the next mobile app.” It just doesn’t work that way. The rule and the emergent behavior often have absolutely no apparent relationship to each other. So how can we find these rules?

One way to do it is to simply look at others and see what they do. Perhaps there are things people do that bring about the behavior. The problem with this approach is that you need to find a source of pretty significant variation in behavior in order to have the best chance of discovering the kind of behavior you are looking for. That leads me to this conclusion: You aren’t going to find it where you work. In fact, you probably aren’t going to find it in your industry (yeah, I’m talking about software). If you are looking for these kind of rules you need to cast your net really wide. Across multiple industries.

If it were me, I’d look into industries like logistics and shipping, I’d look into the printing industry (they are the reigning kings of resource planning). I’d look across different cultures at food vendors in the streets of india, or the techniques that a London cabby uses to remember all of the streets and byways of London. I’d go to emergency call centers, emergency rooms, trucking dispatchers, call centers, anything you can imagine is game. Start with the end state in mind (at least in broad terms) and then work your way down toward the specific building blocks that might get you there. It’s probably a fool’s errand, but at least you are looking for an answer.

Perhaps it can only come from experience?

It reminds me of deer hunting with my father. In the darkest and coldest hours of the early fall morning we would leave our camp to hunt. As we walked out to where ever we were hunting for the day, often we would debate our strategy for the hunt. My Dad always told me that the best strategy was to pick a likely spot and wait for the deer to come to you. If you were patient and sat still, you were much more likely to see something or have a deer come stumbling across your path. He said that’s why old guys were better hunters. They would go out and fall asleep on stump and wake up an hour later to find a monster buck blithely munching away right in front of them. All you have to do is just sit there perfectly quietly. All. Day. Long.

Now to me, as a teenager, this sounded like an excellent recipe for going rather swiftly and completely insane. There we were, out in the hills wandering through what could easily be described as “God’s Country” There was deer habitat everywhere. A herd of deer over every hill. They could be down in the next valley beside the river in the morning. Later in the day they might be high on the ridges bedded down among the rimrocks. The only way to get those deer was to go to where they were. You had to move around and cover some territory.

I spent days roaming the hills and valleys hunting – and finding nothing but dry grass. I would cover 20 miles a day. It turns out that I make a hell of a lot of noise when I’m roaming around. Even when I’m being really sneaky I still make an unholy racket (at least to a deer). They hear you coming a mile off. That’s if they don’t see you silhouetted against the skyline as you cross the ridge. Or if they smell you coming from the next county as you sweat your way up to the rimrocks. It seemed like where ever I went, they were always long gone.

You see each of us was practicing a simple rule. My Dad’s rule: sit still. Mine? Keep moving. So who do did the best? Dad.

Me? I scared the hell out of every deer, fox, mule, turkey and woodchuck in a 20 mile radius. On the bright side, I never spent a dime on bullets.

I eventually learned which rule worked best, but it took me time and experience to get there.

Filed under: Agile, Swarming Tagged: Agile, complexity, Hunting, rules, simple rules, Swarming
Categories: Blogs

Show A Friendly Error Message If A User Specified Image URL Doesn’t Load

Derick Bailey - new ThoughtStream - Sat, 09/20/2014 - 01:46

SignalLeaf allows a podcaster to specify an image for the podcast and/or episodes. To do this, you paste a URL to an image in to an input box. It’s a pretty standard setup, over-all. 


With this being a public facing system, letting people specify any URL they want often leads to mistakes – the most common of which is pasting in a web page URL that contains the image they want. For example, someone might paste a media file location from a WordPress blog, and accidentally paste the view page instead of just the image URL. When this happens, I want to show people a friendly error message to say something went wrong and they need to fix it. Fortunately, this is fairly simple with jQuery and the error / load methods for loading images.

Handling Errors On Image Load

The first thing to set up is a jQuery selector around your image tag, and for the “change” event of the input for the URL. Once you have that, can call the .error method on the img selector object. In this callback, run additional code to show an error message of some kind.

In my case, I’m showing a previously hidden error message and also hiding the image preview “img” tag. The end result looks like this:


(note that I left the single pixel border an image preview space in place, to show that no image was loaded)

Handling Successful Image Load

With the error handler in place, you will also need a success handler for when the image loads properly. You don’t want to continue showing the error message, or hiding the image when it does load successfully after all. 

Modify the existing code to add a .load method call on to the img tag selector. This takes another callback which can be used to show the image preview and hide the error message.

The end result is what I showed in the first screenshot above – a successful image load with the URL in the input box.

A Note On When To Wire This Up

One thing you need to watch for, is when you wire up the .error and .load callback methods. You need to ensure this is done before the <img> has a src attribute – before the image is loaded. If you don’t put the error and load callbacks in place prior to the the image source being set, the callback methods won’t be fired and things won’t work.

A Much Better User Experience

Having a simple set up to show error messages like this is one way to help create a better user experience. Instead of just giving people an input box and hoping for the best, this code provides immediate feedback on whether or not they got it right. Giving your users that kind of knowledge, as quickly as possible, will save a lot of frustration and headache for the people using your system and for the support people who would have to help fix simple mistakes that could have been avoided.

     Related Stories 
Categories: Blogs

Change is Learning: No Silver Bullets or Quick Fixes

Johanna Rothman - Fri, 09/19/2014 - 15:33

Way back when I was a developer, my professors taught me structured design and design by contract. Those were supposed to be the silver bullets for programming.  You see, if you specified things enough, and structured things enough, everything would all work out.

I thought I was the only idiot that structure and specification didn’t work for. Why did I have to iterate and increment?

At my first job, we had design reviews and code reviews. I learned a lot. I worked on a government contract, and the government mandated those reviews. They were useful, and they were supposed to be a silver bullet. Because we implemented features (yes, back in the ’70s, we implemented features), the reviews were helpful in the small.

But, I worked on a program. There is just so much design by contract can do for a program. I was in Boston. I had questions for my counterpart in New Mexico. I was not allowed to talk to that person. (To this day, I don’t know who that person was. That person was part of another subcontractor.) I had to send my questions up through the project management layers to the program team and down the other side. My questions never did get answered. I left that company before I knew if my code worked with the entire system.

I transitioned into project management, program management and people management. I have seen my share of fads, bullets, and fixes for the software departments.

As a director in the early ’90’s I got sent to TQM school (Total Quality Management). My company thought it would change the way we managed, and revolutionize our organization. It would be our “silver bullet.” I’m pretty sure those were somebody’s words. They weren’t mine.

I got a certificate for my five days of intensive training (powerpoint and calculations). I might still have it somewhere.

I became excellent at calculating many costs: the cost of quality, the cost of not doing things right,  the cost of technical debt, even what we might consider the cost of delay. I dutifully explained these costs to my senior management. Was I able to persuade my company of the cost of not doing the right thing, even though I was a middle manager, a program manager, and had been TQM’d?

No. My management was too concerned that doing things “right” would prevent us from making money. I had data—yes, data—that proved them wrong. But their belief systems overcame my data.

Later, after I started my consulting business, many of my clients fell into the ISO 9000 and the CMM/CMMI quick fix/silver bullet traps. The ISO joke made the rounds: “You could specify a cement life jacket with ISO, as long as you define the right process for creating it.” Well, no. But the jokes still persisted. (Many people find value in ISO. Some do not.)

And, with the CMM/CMMI? Oh, my clients had binders full of documentation, but they weren’t releasing software. They hired me on the side, because their silver bullet of CMM/CMMI process wasn’t working. Somehow, my approaches of timeboxes and increments, and iterations, and thinking about their projects was. (Many people find  value in using CMM/CMMI. Some do not.)

Now we have agile. If you read my work, you know I lean towards agile and lean. At the same time, I say that agile is not for everyone. Agile is not a silver bullet.

We have no silver bullets in software.

We have difficult problems to solve. We must think about our approaches, each and every time. We must consider our context. That why I wrote Manage It! Your Guide to Modern, Pragmatic Project Management. Because every single project is unique. That’s why I’m writing Agile and Lean Program Management: Collaborating Across the Organization. That book is a principle-based approach to program management, to scaling agile past one or two teams. Not a one-size fits all approach to program management.

And, because we have no silver bullets in software, and because we have no quick fixes, my management myth this month is We Need a Quick Fix or a Silver Bullet.

It’s very tempting to think that transitioning to agile might be a quick fix or a silver bullet. Transitioning to agile or lean might help you. It won’t be quick.

Any transition is a change. Change takes time. Change is learning. Developing software is learning. You can help yourself learn faster with some approaches: make value obvious instead of tasks, get feedback often, visualize your work, etc. For many of you starting your agile journey, these are cultural changes.

The more you challenge the culture, the longer the change takes because people need to learn what to do and how to work. Cultural change is not a silver bullet. It is certainly not a quick fix.

Read Management Myth 33: We Need a Quick Fix or a Silver Bullet.

Categories: Blogs

Self-management, really?

Business Craftsmanship - Tobias Mayer - Fri, 09/19/2014 - 15:15

The term self-management has become popular recently, often replacing self-organization as the default term for describing agile teams. I don’t like it, and I don’t believe it carries the same meaning—at all.

Our understanding of self-organization comes from chaos theory. Living systems self-organize to optimize their chance of survival, and unless you buy into some kind of “intelligent design” concept it is clear there is no manager for the formation and adaptation of life. Human systems are living systems, therefore human systems self-organize, by definition. The problem is we are taught to be managed out of this natural state of being, by well-meaning people who believe outside control will deliver more effective results.

When I hear “self-managed team” I hear safety. Agile tempts people beyond their comfort zones, but some won’t leap, or even let go. They’ll edge out slowly, holding tightly to their old ideas—just in case. Trouble is, the old ideas then get mistaken for new ideas; they spill into the new paradigm only to dilute it. Is anyone stopping for a moment to consider whether we want management at all? Maybe it’s an idea whose time has come and gone.

The website defines management as “The organization and coordination of the activities of a business in order to achieve defined objectives.” [ref]  Management is concerned with outcomes. I claim that outcomes are too unknowable in the knowledge industry to make such focus useful—indeed, it is detrimental. Our focus needs always to be on exploring the various pathways towards desired (not defined) goals. The goals themselves will change, just as the pathways we take will change. True self-organization allows us to adapt to current context and circumstance, to emerge the next most useful evolutionary change to get where we think we need to go. Attempts to manage this process, whether self-managed or other-managed is likely to have us narrowly focus on idealistic outcomes, and in doing so fail to enjoy the journey—the process of emergence where new and wonderful ideas may be unearthed.

If people and processes were not managed at all, but were just allowed to occur, how might the workplace be different? It’s a thought experiment worth indulging in.

Categories: Blogs

What is Loyalty ?

Agile World - Venkatesh Krishnamurthy - Fri, 09/19/2014 - 14:07

No one plans to fall sick isn't it? Similarly, when I caught some flu couple of years ago, we were eager to see a doctor. Being new to our suburb, googled around to find a nearby medical center. Took an appointment with "any available GP," visited and got better.

After some time, it was my wife's turn. When she wasn't keeping well, she too called the medical center, took an appointment with "any available GP" and felt better.

Apparently she visited a different GP than mine. She recommended me to see him next. Over the course of time, we noted his name and started getting appointment specifically with him when needed. Suddenly one day we heard that he moved out of this medical center, and the receptionist wasn't eager to share his new coordinates.
We felt a bit sad as he knew us well, and we had a built a good rapport over the years and now we don’t know his whereabouts.

Later due to circumstances, we moved to a different suburb and once again started the search for "any available GP". We weren't so happy with the GPs we had seen compared to our earlier one. We used to remember our earlier GP once in a while.

One day we casually thought of searching our earlier GPs name on google, and some names came up. We called a few and one of them actually turned out to be our earlier GP. Everyone was elated, and we went and met him as well. He was not only surprised to see us but was beaming with a big smile.

I would call our selves as the loyal customers for this GP as we did everything we could do get the services only from him even when several options were available.

Loyalty is something when you chose a specific service inspite of having many options in available to you. Of course, a more formal definition from Wikipedia would be “Loyalty is faithfulness or a devotion to a person, country, group, or cause.”

On the other hand, repeat business is something where customers use existing service as they don't have an alternate option.

It is shameful to see that many companies measure "repeat business" rather than "loyalty." Loyalty is much more powerful than getting a repeat customer. Loyalty is something that will enable the company to grow during downturns and fierce competition. Repeat customer will leave you and go when they find better options.

Nowadays companies rollout the so-called "loyalty program." Big shopping malls and airlines have this loyalty program. I feel that this is a bit misnomer. People tend to go back to these companies not because they like the service, but because they get some discounts or redeemable reward points. I don't call such programs as a "loyalty programs", but as "carrot programs."

Couple of things I liked about our family GP has been his relationship building skills, his frankness, his specialty, customer service and respect for us.

Here is another personal example, while I moved to a new suburb, I was scouting for an electricity provider. I was calling each provider and gathering various details. As one could see, each one was tried their level best to sell a service by sharing their discount program, except one of them who explained their weaknesses as well. She not only suggested alternate but better options. I genuinely got connected with this company. Lesson learnt, being truthful and genuine breeds loyalty.

To conclude, It is very important for a business to evaluate if the returning customer is a loyal one or a repeat.

Even though we have tools like NPS, it won't clearly tell you the difference between loyalty and repeat. It partially helps to understand the situation though.

Always try to build a loyal customer base and work towards converting the repeat customers to loyal ones.

I have also posted this article on LinkedIn

Categories: Blogs

Docker-izing enterprise software

Xebia Blog - Fri, 09/19/2014 - 13:56

I’ve spent Xebia’s Innovation Day last August experimenting with Docker in a team with two of my colleagues and a guest. We thought Docker sounds really cool, especially if your goal is to run software that doesn’t require lots of infrastructure and can be easily installed, e.g. because it runs from a jar file. We wondered however what would happen if we tried to run enterprise-software, like an Oracle database. Software that is notoriously difficult to install and choosy about the infrastructure it runs on. Hence our aim for the day: install an Oracle database on CoreOS and Docker.

We chose CoreOS because of its small footprint and the fact that it is easily installed in a VM using Vagrant (see We used default Vagrantfile and CoreOS files with one modification: $vb_memory = 2024 in config.rb which allows the Oracle’s pre installer to run. The config files we used can be found here:

Starting with a default CoreOS install we then implemented the steps described here:
Below is a snippet from the first version of our Dockerfile (tag: b0a7b56).
FROM centos:centos6
# Step 1: Setting Hostname
# Step 2
RUN yum -y install wget
RUN wget --no-check-certificate -O /etc/yum.repos.d/public-yum-ol6.repo
RUN wget --no-check-certificate -O /etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
RUN yum -y install oracle-rdbms-server-11gR2-preinstall

Note that this takes awhile because the pre installer downloads a number of CentOS packages that are missing in CoreOS.
Execute this in a shell:
vagrant up
vagrant ssh core-01
cd ~/share/docker
docker build -t oradocker .

This seemed like a good time to do a commit to save our work in Docker:
docker ps # note the container-id and substitute for the last parameter in the line below this one.
docker commit -m "executed pre installer" 07f7389c811e janv/oradocker

At this point we studiously ignore some of the advice listed under ‘Step 2’ in Tecmint’s install manual, namely adding the HOSTNAME to /etc/syconfig/network, allowing access to the xhost (what would anyone want that for?) and mapping an IP address to a hostname in /etc/hosts (setting the hostname through ‘ENV HOSTNAME’ had no real effect as far as we could tell). We tried that but it didn’t seem to work. Denying reality and substituting our own we just ploughed on…

Next we added Docker commands to the Dockerfile that creates the oracle user, copy the relevant installer files and unzip them. Docker starts by sending a build context to the Docker daemon. This takes quite some time because the Oracle installer files are large. There’s probably some way to avoid this, but we didn’t look into that. Unfortunately Docker copies the installer files each time you run docker -t … only to conclude later on that nothing changed.

The next version of our Dockerfile sort of works in the sense that it starts up the installer. The installer then complains about missing swap space. We fixed this temporarily at the CoreOS level by running the following commands:
sudo su -
swapfile=$(losetup -f)
truncate -s 1G /swap
losetup $swapfile /swap
mkswap $swapfile
swapon $swapfile

found here:
This works but it doesn’t survive a reboot.
Now the installer continues only to conclude that networking is configured improperly (one of those IgnoreAndContinue decisions coming back to bite us):
[FATAL] PRVF-0002 : Could not retrieve local nodename

For this to work you need to change /etc/hosts which our Docker version doesn’t allow us to do. Apparently this is fixed in a later version, but we didn’t get around to testing that. And maybe changing /etc/sysconfig/network is even enough, but we didn't try that either.

The latest version of our work is on github (tag: d87c5e0). The repository does not include the Oracle installer files. If you want to try for yourself you can download the files here: "> and adapt the docker file if necessary.

Below is a list of ToDo’s:

  1. Avoid copying large installer files if they’re not gonna be used anyway.
  2. Find out what should happen if you call ‘ENV HOSTNAME’.
  3. Make swap file setting permanent on CoreOS.
  4. Upgrade Docker version so we can change /etc/hosts

All in all this was a useful day, even though the end result was not a running database. We hope to continue working on the ToDo’s in the future.

Categories: Companies

How I spent $75,000 during a budget freeze

Derick Bailey - new ThoughtStream - Fri, 09/19/2014 - 13:00


$75K in Hardware/Software

That’s how much I spent, during a budget freeze at the company where I worked!

It was 2008 – a bad year for a lot of companies in the United States (and beyond). The company for which I worked was no exception and we were hit with a budget freeze. No one was allowed to buy anything above a small amount ($500 or so, I think) without CEO approval. It hit us all, hard. There wasn’t a single department, team or project that went unaffected. No one was happy.

A few months in to the budget freeze, though, I got the CIO and CEO to sign off on my purchase order of $75,000 for a virtualization environment. It took less than 1 week to go from me saying “we need this,” to the CEO saying, “where do I sign?” – all while everyone else looked on, mouths dropping to the floor as they couldn’t get a $750 request approved.

I would love to tell you how great I am and how easy this was… but that would be a lie. I got lucky with this – but I believe it’s repeatable luck, because I’m pretty good at listening, and applying principles and patterns to new situations… and it was 2 years earlier that I learned what allowed me to spend this money in 2008.

2006: A Lesson Learned In Time / Money

In 2006, the same company as above was needed to build a fancy user interface for a project with accessibility requirements for disabled persons. The UI control suite I had been using failed miserably. I quickly found a new one and started using it on the project. A few months later, another project needed similar things so I proposed buying a site license for the company.

After continuously being denied my request, I was about ready to give up. My manager sat down with me to discuss it and asked me to justify the cost to him. How would it save the company money, or help the company earn more money? I had no answer. It wouldn’t save money – only development time.

He quickly pointed out that time is money and after some discussion, we had a rough estimate of how many hours it would save us to buy the UI control suite vs build it ourselves. Multiply the average developer hourly rate by the hours to build, and it was obvious that the expense of the control suite was justified. I wrote down those numbers and reasons, and got the control suite purchased.

Back to 2008: Buying In A Budget Freeze

When the budget freeze hit I knew we needed those virtualization servers, but I couldn’t justify the cost. Then something bad happened, and an opportunity presented itself. We had a server crash caused by software conflicts between projects on a single physical server. After nearly 2 weeks of work form the I.T. Department moving projects around and re-installing software in production environments, everything was back up and I had my justification.

I spoke with the I.T. persons that were involved in the cleanup from the crash and got an estimate of how much time they spent on it. I talked to project managers for the affected projects and got an estimate of time and revenue lost due. I asked about replacement hardware and new hardware costs associated with the crash and fix.

I took all of the information I had gathered and compiled it in to a document that very clearly outlined how much money we had spent, how much we lost, the risk similar projects in the future and how much the virtualization setup I was requesting would cost. The $75,000 I wanted to spend would save us a lot of money very quickly, as the company continued to grow.

After a few days of gathering and documenting everything, the CIO signed the purchase order. The CEO was out that day but signed it as soon as he got back, on the advisement of the CIO. I had my servers in the middle of a budget freeze!

Lesson Learned: Speak Like Your Audience

In the end, I was able to justify $75,000 during a budget freeze, because I took the time to research and write a document that outlined the pain points that the CIO and CEO cared about: lost revenue, lost developer time, unnecessary money spent, etc.

Everyone talks about how you need to know your audience when doing public speaking, teaching, training, etc. But the same holds true in any job as well. Whether it’s a CEO, a customer in your store or whoever it is, you need to know how your audience thinks and what makes them tick. You need to understand how they see pain, what pain they currently see, and how you can address that pain with your proposed solutions. If you can do this, there’s a good chance you’ll be able to get the things you need.

– Derick

Categories: Blogs

Killing 7 Impediments in One Blow

Agile Tools - Fri, 09/19/2014 - 08:13

Have you heard the story of the Brave Little Taylor? Here’s a refresher:

So one day this little guy kills 7 flies with one mighty blow. He crafts for himself a belt with “7 in One Blow” sewn into it. He then proceeds through various feats of cleverness to intimidate or subdue giants, soldiers, kings and princesses. Each one, in their own ignorance, misinterpreting what “7 in One Blow” actually refers to. It’s a classic for a number of reasons:

  1. It’s a story about mis-communication: Not one single adversary has the wit to ask just what he means by killing “7 in one blow”
  2. It’s also a story about using one’s cleverness to achieve great things. You have to love the ingenuity of the little guy as he makes his way adroitly past each obstacle.
  3. It’s a story about blowing things way out of proportion. Each of the tailor’s adversaries manages to magnify the capabilities of the tailor to extraordinary, even supernatural levels.

I’m thinking I might have to get a belt like that and wear it around the office. A nice pair of kahkis, a button down shirt, and a big belt with the words, “7 in One Blow”. Given how prone we all tend to be to each of the foibles above, I’m sure it would be a riot.
A QA guy might see my belt and say, “Wow! He killed 7 bugs in one blow!”
Maybe a project manager might see it and think, “This guy is so good he finished 7 projects all at once!” Or maybe the HR rep says, “Did he really fire 7 people in one day?” Or the Scrum Master who thinks, “That’s a lot of impediments to clear out at once!”
The point is that we make up these stories all the time. We have stories in our heads about our team mates, “Did you hear about Joe?” our managers, and their managers. Sometimes it seems as though we all have these distorted visions of each other. And perhaps we do. We need to get better at questioning those stories. We need to cultivate more of a sense of curiosity about the incomplete knowledge that we have of each other. That belt would be my reminder. I might have to buy one for each member of my team.
Of course the other thing that the belt can remind us of, is to use our own innate cleverness to help get what we need. When we are wrestling with the corporate challenges, we all too often tend to try and brute force our problems and obstacles. We need to be a bit more like the Little Tailor and manipulate the world around us with some cleverness. We all have it to one degree or another, and Lord knows we need all the cleverness we can get. Good work is full of challenges and you don’t want to take them all head on or you will end up like an NFL linebacker – brain damaged. Instead, we need to approach some things with subtlety. There is just as much value in not being in the path of a problem as there is in tackling things head on. Like the Tailor, we need to recruit others to achieve our objectives.
Finally, we really must stop blowing things out of proportion. Nobody cares about our methodology. You want to know what my favorite kind of pairing is? Lunch! We need to lighten up a bit. Working your way through the dark corporate forest, you can either play with what ever it brings and gracefully dodge the risks, or…you can get stepped on.

Filed under: Agile, Coaching, impediment, Process, Teams Tagged: cleverness, fool, Process, Teams, wit
Categories: Blogs

The Agile Reader – Weekend Edition: 09/19/2014 - Kane Mar - Fri, 09/19/2014 - 06:16

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.

  • #RT #AUTHORRT #scrum that works ** ** #agile #project #productowner
  • Even better – communicating while drawing! #Scrum #Agile
  • #Agile – How does Planning Poker work in Agile? –
  • Scrum Expert: Increasing Velocity in a Regulated Environment #agile #scrum
  • RT @yochum: Scrum Expert: Increasing Velocity in a Regulated Environment #agile #scrum
  • RT @yochum: Scrum Expert: Increasing Velocity in a Regulated Environment #agile #scrum
  • RT @yochum: Scrum Expert: Increasing Velocity in a Regulated Environment #agile #scrum
  • #Meetings! Huh! What are they good for? #scrum
  • @Dell is hiring #SDET, #Austin, TX #Iwork4Dell #ecommerce #agile #Scrum
    #dotnet #Automation #testing @CareersAtDell
  • Medical Mutual #IT #Job: Agile Scrum Master – Project Manager 14-266 (#Strongsville, OH) #Jobs
  • Has #Scrum Killed the Business Analyst? #scrumrocks #agile #yrustilldoingwaterfall
  • RT @yochum: Scrum Expert: Increasing Velocity in a Regulated Environment #agile #scrum
  • Scrum Master at Agile (Atlanta, GA): : Our client is focused on building a platform and related… #ATL
  • How to Plan an Agile Sprint Meeting? –
  • Agile Scrum isn’t a silver bullet solution for s/w development, but it can be a big help. #AppsTrans #HP
  • Now hiring for: Scrum Master in Gainesville, FL #job #agile #mindtree
  • Scaling Agile Your Way: SAFe vs. MAXOS (Part 2 of 4) #agile #scrum
  • RT @yochum: Scaling Agile Your Way: SAFe vs. MAXOS (Part 2 of 4) #agile #scrum
  • RT @yochum: Scaling Agile Your Way: SAFe vs. MAXOS (Part 2 of 4) #agile #scrum
  • Agile Scrum #Master needed in #SanFrancisco, apply now at #Accenture! #job
  • RT @SpitFire_: How to Attract #Agile Development Talent @appvance #Tech #Scrum @lgoncalves1979 @kevinsurace #TechJo…
  • RT @SpitFire_: How to Attract #Agile Development Talent @appvance #Tech #Scrum @lgoncalves1979 @kevinsurace #TechJo…
  • RT @SpitFire_: How to Attract #Agile Development Talent @appvance #Tech #Scrum @lgoncalves1979 @kevinsurace #TechJo…
  • RT @SpitFire_: How to Attract #Agile Development Talent @appvance #Tech #Scrum @lgoncalves1979 @kevinsurace #TechJo…
  • RT @SpitFire_: How to Attract #Agile Development Talent @appvance #Tech #Scrum @lgoncalves1979 @kevinsurace #TechJo…
  • RT @SpitFire_: How to Attract #Agile Development Talent @appvance #Tech #Scrum @lgoncalves1979 @kevinsurace #TechJo…
  • RT @SpitFire_: How to Attract #Agile Development Talent @appvance #Tech #Scrum @lgoncalves1979 @kevinsurace #TechJo…
  • FREE SCRUM EBOOK based on the AMAZON BESTSELLER: #scrum #agile inspired by #kschwaber
  • RT @SpitFire_: How to Attract #Agile Development Talent @appvance #Tech #Scrum @lgoncalves1979 @kevinsurace #TechJo…
  • RT @SpitFire_: How to Attract #Agile Development Talent @appvance #Tech #Scrum @lgoncalves1979 @kevinsurace #TechJo…
  • RT @SpitFire_: How to Attract #Agile Development Talent @appvance #Tech #Scrum @lgoncalves1979 @kevinsurace #TechJo…
  • RT @SpitFire_: How to Attract #Agile Development Talent @appvance #Tech #Scrum @lgoncalves1979 @kevinsurace #TechJo…
  • RT @SpitFire_: How to Attract #Agile Development Talent @appvance #Tech #Scrum @lgoncalves1979 @kevinsurace #TechJo…
  • RT @SpitFire_: How to Attract #Agile Development Talent @appvance #Tech #Scrum @lgoncalves1979 @kevinsurace #TechJo…
  • RT @SpitFire_: How to Attract #Agile Development Talent @appvance #Tech #Scrum @lgoncalves1979 @kevinsurace #TechJo…
  • RT @SpitFire_: How to Attract #Agile Development Talent @appvance #Tech #Scrum @lgoncalves1979 @kevinsurace #TechJo…
  • You get more value from periodic “lessons learned” events rather than a big one at the end #agile #scrum #PMI
  • RT @SpitFire_: How to Attract #Agile Development Talent @appvance #Tech #Scrum @lgoncalves1979 @kevinsurace #TechJo…
  • RT @tirrellpayton: You get more value from periodic “lessons learned” events rather than a big one at the end #agile…
  • A Quick, Effective Swarming Exercise for Scrum Development Teams #agile #projectmanagement
  • RT @yochum: Agile Tools: The Grumpy Scrum Master #agile #scrum
  • +1 The #agile mindset: It’s time to change our thinking, not #Scrum #agile #scrum (via @sdtimes)
  • Agile by McKnight, Scrum by Day is out! Stories via @dinwal @StratacticalCo
  • SCRUM EBOOK #Scrum #Agile inspired by #Ken Schwaber
  • RT @MRGottschalk: “Think Scrum is Only for Developers? Think Again.” by @MRGottschalk on @LinkedIn #Scrum #Agile
  • RT @FreeScrumEbook: SCRUM EBOOK #Scrum #Agile inspired by #Ken Schwaber
  • #RT #AUTHORRT #scrum that works ** ** #agile #project #productowner
  • RT @MichaelNir: #RT #AUTHORRT #scrum that works ** ** #agile #project #productowner
  • RT @MichaelNir: #RT #AUTHORRT #scrum that works ** ** #agile #project #productowner
  • Want to know more about Agile? Sign up to our free workshop #Scrum #agile
  • RT @boostagile: Want to know more about Agile? Sign up to our free workshop #Scrum #agile
  • RT @HPappsServices: Agile Scrum isn’t a silver bullet solution for s/w development, but it can be a big help. #Apps…
  • Does your agile process look like this? via @joescii
  • #jobs4u #jobs Scrum Master / Agile Coach #RVA #richmond #VA
  • Why do we “think” we “need” estimates? Its worth thinking about. #agile #scrum #kanban #NoEstimates
  • Check it out – FREE SCRUM EBOOK: #Scrum #Agile inspired by #KenSchwaber
  • Categories: Blogs

    Scaling Agile Your Way: SAFe vs. MAXOS (Part 2 of 4)

    Agile Management Blog - VersionOne - Thu, 09/18/2014 - 23:03

    In Part 1 of this four-part blog series, I explained why a cookie-cutter approach will not work as you undertake large-scale agile initiatives.  Each agile project developing a product or a solution has a unique context:  assumptions, situation, team members and their skill sets, organizational structure, management understanding and support, maturity of practices, challenges, culture, etc.

    In Part 1, I proposed a fairly comprehensive list of 25 scaling agile parameters classified into six scaling aspects:

    1.  Teams
    2.  Customers/Users
    3.  Agile Methods and Environments
    4.  Product/Solution
    5.  Complexity
    6.  Value Chain (see Tables 1 through 4 of Part 1 of this blog series)

    Each scaling agile parameter can assume one or more values from a range of values.  This comprehensive (but by no means, complete or exhaustive) list of 25 scaling agile parameters suggests that the agile scaling space is complex and rich with many choices.  Each organization or large-scale project is likely to select a different combination of these 25 scaling agile parameters that are relevant; moreover, the value or range of values for each scaling agile parameter for a project or an organization is likely to be unique.  However, in Part 1, I also clarified that “Scaling Agile Your Way” does not imply a license to optimize at the subsystem levels (teams or programs) at the expense of overall system-level optimization (portfolios and enterprise).  Systems thinking is important for Scaling Agile Your Way.

    In Part 1, I presented a brief overview of various popular Agile and Lean scaling frameworks: Scaled Agile Framework® (SAFe™), LeSS, DAD and MAXOS.  Although there are differences among SAFe, LeSS and DAD, they all are radically different from MAXOS.  In this part of the series, I will compare and contrast SAFe vs. MAXOS in some depth.

    Briefly, here are the key highlights of SAFe.  Details can be found at Scaled Agile Framework:

    • SAFe requires a “Portfolio, Program and Teams” hierarchy for a large-scale agile project.
    • Each team must be a cross-functional Scrum team and may follow many XP practices.
    • Epics at portfolio levels are managed as a Lean/Kanban flow.  Epics are broken down into features that can be completed in a single release cycle at the program level; each feature is broken down into stories that can be completed in a single sprint at the team level.
    • All teams in a release train of a program must follow the same lock-step sprint cadence (typically two weeks).
    • Release train planning requires all team members (typically up to 150) from all teams in a program to hold two-day-long release planning meetings in person, which entails a substantial effort and complex logistics.
    • Release cycles are typically eight to 12 weeks long.
    • Software is developed on sprint cadence, and released on demand (but cannot be released faster than the sprint cadence).
    • Considerable time and effort is spent in various ceremonies:  sprint planning, sprint review and sprint retrospectives, release train planning across multiple teams, release review and release retrospectives, etc.

    Briefly, here are the highlights of MAXOS.  Details can be found in Andy Singleton’s Agile 2014 presentation.

    • MAXOS is the scaling approach for “Continuous Agile.”  Continuous Agile combines Kanban Agile task management with continuous delivery code management. 
    • MAXOS requires a number of (almost) independent service teams.
    • Services have well-defined APIs, are loosely coupled, and have minimal dependencies among them.
    • Each team operates with Lean flow.  Applications are rapidly composed of a group or a network of services.
    • Each team is developer-centric (not cross-functional) and highly empowered.
    • Code is continually integrated in a single code base across all teams.
    • Code is continually tested with automated tests (unit, acceptance, regression, etc.) by firing off as many virtual machines as needed in a cloud-based environment.
    • Any dependency issues across teams are immediately resolved via rapid team-to-team communication.  For rapid team-to-team or member-to-member communication, tool support is essential. VersionOne provides excellent communication and collaboration among team members.
    • The typical ratio of developers to testers tends to be 10:1, as teams are developer-centric and developers do most automated testing.   There are no separate QA teams.  QA testers are called as needed for their expertise by developer-centric teams.
    • Each empowered, developer-centric team decides when to release its code (not decided by QA testers or product managers!).  MAXOS claims that this policy rationally aligns the interests of developers with consequences of their release decision; poorly written, poorly reviewed, or inadequately tested code may mean “no weekends” or “No Friday evening beer” for developers!
    • All features or stories have switches (togglers) that the product owner (called story owner) decides to turn on (unblock) or turn off (block) based on the market needs.
    • Code released in production is extensively supported by automated user feedback collection, measurements and analysis that result in actionable reports for product management.
    • Automated feedback from production environment is also used directly by developers to immediately fix problems.
    • Meeting time is minimized by “automating away” management meetings, and removing or reducing other Scrum ceremonies.  For example, sprint and release retrospectives are replaced by periodic “Happiness Surveys” and taking actions based on those surveys.

    Because of these fundamental differences between SAFe and MAXOS, they represent radically different approaches to scaling agile. The contrast between SAFe and MAXOS is breathtaking, and its implications are worth understanding.  Tables 5-10 present the differences between SAFe and MAXOS from the perspective of 25 scaling agile parameters covered in Tables 1-4 of Part 1.

    These six tables (Tables 5-10 below) follow a specific color legend described below:








    Are your agile projects closer to the SAFe Sweet Spot or the MAXOS Sweet Spot? 

    Or are your projects closer to the SAFe Challenge Zone or the MAXOS Challenge Zone?  Or are you in a situation where neither SAFe nor MAXOS will serve you unique agile scaling needs? If you are exploring the use of LeSS or DAD framework, I would encourage you to use the list of 25 scaling agile parameters to identify the Sweet Spot, Challenge Zone and Unfit Zone for LeSS or DAD (as I have done in Tables 5-10 for SAFe and MAXOS). Then determine if your projects are closer to the Sweet Spot or Challenge Zone of LeSS or DAD.

    I would love to hear from you either in the Comments below, by email (, or on Twitter @smthatte.

    Related posts:

    Part 1: Scaling Agile Your Way: Agile Scaling Aspects and Context Matter Greatly

    Stay tuned for these future parts of this series:

    Part 3: Scaling Agile Your Way – Sweet Spot, Challenge Zone and Unfit Zone for SAFe and MAXOS

    Part 4: Scaling Agile Your Way – How to develop and implement your custom approach

    Categories: Companies

    iOS 8: The biggest iOS release ever

    Derick Bailey - new ThoughtStream - Thu, 09/18/2014 - 20:22

    I updated my iPad to iOS 8 yesterday.

    IOS8 big release

    (and, yes… I drew this on my iPad)

         Related Stories 
    Categories: Blogs

    Increasing Velocity in a Regulated Environment

    Scrum Expert - Thu, 09/18/2014 - 20:10
    In regulated industries like Health Care you have to comply with standard operating procedures, heaps of paper work and frequent audits. Do these requirements conflict with the core tenets of Agile? How do you increase velocity in such regulated environments? This presentation explains how PHT Corporation overcame these constraints and got to Agile. He will draw a picture of PHT’s operating environment and the applicable regulations for software development. He demonstrates how the required documentation can become a byproduct of the everyday work of a Scrum team and describes changes he ...
    Categories: Communities

    Management Innovation is at the Top of the Innovation Stack

    J.D. Meier's Blog - Thu, 09/18/2014 - 18:13

    Management Innovation is at the top of the Innovation Stack.  

    The Innovation Stack includes the following layers:

    1. Management Innovation
    2. Strategic Innovation
    3. Product Innovation
    4. Operational Innovation

    While there is value in all of the layers, some layers of the Innovation Stack are more valuable than others in terms of overall impact.  I wrote a post that walks through each of the layers in the Innovation Stack.

    I think it’s often a surprise for people that Product or Service Innovation is not at the top of the stack.   Many people assume that if you figure out the ultimate product, then victory is yours.

    History shows that’s not the case, and that Management Innovation is actually where you create a breeding ground for ideas and people to flourish.

    Management Innovation is all about new ways of mobilizing talent, allocating resources, and building strategies.

    If you want to build an extremely competitive advantage, then build a Management Innovation advantage.  Management Innovation advantages are tough to copy or replicate.

    If you’ve followed my blog, you know that I’m a fan of extreme effectiveness.   When it comes to innovation, I’ve had the privilege and pleasure of playing a role in lots of types of innovation over the years at Microsoft.   If I look back, the most significant impact has always been in the area of Management Innovation.

    It’s the trump card.

    Categories: Blogs

    Agile Practitioners Conference, Kuala Lumpur, Malaysia, October 2-3 2014

    Scrum Expert - Thu, 09/18/2014 - 17:46
    Agile Practitioners Conference Malaysia is a two-day conference focused on Agile, Scrum, Lean, Kanban and UX that takes palace in Kuala Lumpur. In the agenda you can find topics like “(The Rise and Fail of) Fake Agile”, “Describing the Elephant in the Room: User Experience (UX)”, “Overcoming Scrum Implementation Challenges in the Asian Business Environment”, “Agile Requirements: From Planning to Execution” Web site: Location for the 2014 conference: KH Tower, Jalan Punchak, Off Jalan P.Ramlee, 50250 Kuala Lumpur, Malaysia.
    Categories: Communities

    STARWEST, Anaheim, USA, October 12-17 2014

    Scrum Expert - Thu, 09/18/2014 - 17:41
    STARWEST is a six-day software event and conference that features pre-conference training, in-depth half- and full-day tutorials and conference sessions covering major software testing issues and solutions. In the agenda you can find topics like “Real-World Software Testing with Microsoft Visual Studio”, “A Rapid Introduction to Rapid Software Testing”, “Test Automation Patterns: Issues and Solutions”, “Testing Ajax and Mobile Apps with Agile Test Management and Tools”, “A Tester’s Guide to Collaborating with Product Owners”, “Agile Development and Testing in a Regulated”, “Test Improvement in Our Rapidly Changing World”, “The Role of ...
    Categories: Communities

    Agile Advice Book Update

    Learn more about our Scrum and Agile training sessions on

    Well, last spring I announced that I was going to be publishing a collection of the best Agile Advice articles in a book.  I managed to get an ISBN number, got a great cover page design, and so it is almost done.  I’m still trying to figure out how to build an index… any suggestions would be welcome!!!  But… I’m hoping to get it published on iBooks and Amazon in the next month or two.  Let me know if you have any feedback on “must-have” Agile Advice articles – there’s still time to add / edit the contents.

    There are six major sections to the book:

    1. Basics and Foundations
    2. Applications and Variations
    3. Agile and Other Systems
    4. For Managers and Executives
    5. Bonus Chapters
    6. Agile Methods Quick Reference and Selection Guide

    The book will also have a small collection of 3 in-depth articles that have never been published here on Agile Advice (and never will be).  The three special articles are:

    1. Agile Mining at a Large Canadian Oil Sands Company
    2. Crossing the Knowing-Doing Gap
    3. Becoming a Professional Software Developer

    Again, any feedback on tools or techniques for creating a quick index section on a book would be great.  I’m using LibreOffice for my word processor on a Mac.  I’m cool with command-line tools if there’s something good!


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

    Who owns the meetings in Scrum?

    Growing Agile - Thu, 09/18/2014 - 14:31

    We are coaching a new team to use Scrum, and a question has popped up about who owns the various meetings in Scrum. Many people think that because the ScrumMaster is responsible for the process, they own all the Scrum meetings. If that’s you, just pause and go on a thought journey with me.

    One of our favourite sayings is:

    You do it, you own it

    The ScrumMaster is a facilitator in the majority of Scrum meetings – but does that make them an owner? If the ScrumMaster is the one scheduling all the meeting and taking notes etc – then they own the meeting. Scrum is not the ScrumMasters process. They are merely there to guide and coach the teams and Product Owners. Let me explain each meeting.

    Backlog Grooming (or Backlog Refinement)

    The outcome of this meeting is that the team has a better understanding of requirements and that stories are sized. The person who needs the estimates, and will be explaining the requirements is the Product Owner. The ScrumMaster ensures everyone is on the same page, checks the time box and perhaps structures the meeting – this is a facilitative role. The ScrumMaster should not be contributing to the content of the meeting.

    Sprint Planning Part 1

    This meeting is to check understanding and make a commitment for the sprint. Once again, the Product Owner is really interested in this outcome. The ScrumMaster is a facilitator.

    Sprint Planning Part 2

    This meeting is for the team to design and chat about how they are going to do each story. This meeting is for the team. The ScrumMaster can facilitate this, or they can ask the team to facilitate this. However, unless someone in the team has facilitation experience, I would suggest this be the ScrumMaster.

    Daily Scrum

    This is for the team to checkin with each other and their commitment. So the team own it. The ScrumMaster is there as a facilitator only, and occasionally should let the team do their own facilitation.

    Sprint Review

    This meeting is about the product/project and where you are as a team with the release. The Product Owner cares about this and therefore owns this meeting. The ScrumMaster facilitates. And remember facilitation means not adding any content!

    Sprint Retrospective

    This meeting is about the process of the team. It is for the team and should be owned by them. The ScrumMaster is the impartial facilitator.

     Who owns the meetings in Scrum?

    Should the facilitator or owner for any meeting not be available (maybe they are off sick or on training) then decide at the start of the meeting who will play which role. It is not a good idea for a facilitator (who should be impartial) to own and run a meeting.

    My personal preference is to have the owner of the meeting schedule the meeting and NOT the ScrumMaster. Let the people who need the meeting own it. If you’re a ScrumMaster and you currently schedule all the meetings, explain why you don’t want to do this anymore and ask someone else to schedule the meetings important to them. Remember “You do it, you own it!”.

    Categories: Companies

    Full width iOS Today Extension

    Xebia Blog - Thu, 09/18/2014 - 11:57

    Apple decided that the new Today Extensions of iOS 8 should not be the full width of the notification center. They state in their documentation:

    Because space in the Today view is limited and the expected user experience is quick and focused, you shouldn’t create a widget that's too big by default. On both platforms, a widget must fit within the width of the Today view, but it can increase in height to display more content.


    This means that developers that create Today Extensions can only use a width of 273 points instead of the full 320 points (for iPhones pre iPhone 6) and have a left offset of the remaining 47 points. Though with the release of iOS 8, several apps like DropBox and Evernote do seem to have a Today Extension that uses the full width. This raises question wether or not Apple noticed this and why it came through the approval process. Does Apple not care?

    Should you want to create a Today Extension with the full width yourself as well, here is how to do it (in Swift):

    override func viewWillAppear(animated: Bool) {
        if let superview = view.superview {
            var frame = superview.frame
            frame = CGRectMake(0, CGRectGetMinY(frame), CGRectGetWidth(frame) + CGRectGetMinX(frame), CGRectGetHeight(frame))
            superview.frame = frame

    This changes the super view (Today View) of your Today Extension view. It doesn't use any private Api's, but Apple might reject it for not following their rules. So think carefully before you use it.

    Categories: Companies

    Compromises in setting up teams in a scaled framework

    Scrum 4 You - Thu, 09/18/2014 - 07:16

    Making the first steps in setting up a scaled framework with agile teams in a complex environment does not always allow to set up teams by the book. Rather than dragging people from their current activities and having everybody dislike agile, before we have even really started using and living it, I try to make compromises.

    By working in very short sprints of one week, I allow team members to switch between teams with every start of a new sprint. For the one sprint however, they commit to be fully engaged in the sprint backlog and team activities of the one single team. Product owners can plan with the team members’ knowledge for some sprints. The team can make the experience i.e. every other sprint what they are capable of on their own and build confidence and see where they still need more knowledge transfer and help. Multi skilled team members can learn step by step to let go their „baby“ and still be engaged in the field of the product.

    An alternative in the same situation might be:
    If there is a huge overlap in skills needed for one and the other team or part of the product, try putting the teams to either being one team. Build rather large teams in the beginning covering two backlogs (should not be more). Creating a team backlog rather than a product backlog allows the others to learn about the other parts of the product by just being in the team and does not force team members to leave one or the other part of the product without their experience and knowledge.
    Forcing the teams into a decision for one or the other might lead to the opposite – double work by only making one part transparent or frustrated „left alone teams“ and multi skilled team members with feelings of guilt.

    What else have you tried?

    Related posts:

    1. Sprint Planning with geographically dispersed teams located in different timezones
    2. Scrum Teams – No Part Time!
    3. How internationally distributed Teams can improve their Sprint Planning 2

    Categories: Blogs

    The Grumpy Scrum Master

    Agile Tools - Thu, 09/18/2014 - 06:54

    grumpy dwarf

    “Going against men, I have heard at times a deep harmony
    thrumming in the mixture, and when they ask me what
    I say I don’t know. It is not the only or the easiest
    way to come to the truth. It is one way.” – Wendell Berry

    I looked in the mirror the other day and guess what I saw? The grumpy scrum master. He comes by sometimes and pays me a visit. Old grumpy looked at me and I looked at him and together we agreed that perhaps, just this one time, he just might be right.

    We sat down and had a talk. It turns out he’s tired and cranky and seen this all before. I told him I can relate. We agreed that we’ve both done enough stupid to last a couple of lifetimes. No arguments there. He knows what he doesn’t like – me too! After a little debate, we both agreed we don’t give a damn what you think.

    So we decided it was time to write a manifesto. That is

    We grumps have come to value:

    Speaking our mind over listening to whiners

    Working hard over talking about it

     Getting shit done over following a plan

    Disagreeing with you over getting along

    That is, while the items are the right are a total waste of time, the stuff on the left is much more gratifying.


    Filed under: Coaching, Humor, Scrum Tagged: bad attitude, grumpy, Humor, Scrum, Scrum Master
    Categories: Blogs

    Knowledge Sharing

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