Skip to content

Feed aggregator

Do You Need to Create Virtual Teams with Freelancers?

Johanna Rothman - Wed, 06/25/2014 - 14:30

Have you seen Esther Schindler’s great article yet? Creating High-Performance Virtual Teams of Freelancers and Contractors.

Here’s the blurb:

Plenty has been written about telecommuting for employees: how to encourage productivity, build a sense of “we’re all in this together,” and the logistics (such as tools and business processes) that streamline a telework lifestyle. But what about when your team is neither employees nor on-site? That gives any project manager extra challenges.

Lots of good tips.


Categories: Blogs

Cape Town July 2014 – Building a great product

Scrum User Group of South Africa - Wed, 06/25/2014 - 12:58
SUGSA’s monthly Cape Town gathering will be held on 3 July at Allan Gray. See event for more details.
Categories: Communities

How Agile accelerates your business

Xebia Blog - Wed, 06/25/2014 - 11:11

This drawing explains how agility accelerates your business. It is free to use and distribute. Should you have any questions regarding the subjects mentioned, feel free to get in touch.

Categories: Companies

Scrum Day Europe, Amsterdam, Netherlands, July 3 2014

Scrum Expert - Wed, 06/25/2014 - 09:50
Scrum Day Europe is a one-day conference dedicated to Scrum. The 2014 edition of this conference dedicated to agile project management will take place in Amsterdam and will features expert speakers like Ken Schwaber. This is a main event for all European Scrum practitioners. In the agenda up you can find topics like “Led Zepelin Scaling Agility”, “Agile Transformation of a 20,000 Person Company – a Long Term Journey”, “Serious Play on the Path to Agility”, “Using Lean UX to build the right things”, “Product Owner Value Game” or “Agile Myth ...
Categories: Communities

What constitutes “minimally viable agile”?

Silver Stripe Blog - Wed, 06/25/2014 - 07:56

There is an interesting discussion on LinkedIn on “minimally viable agile“. What is the bare minimum that a team should do in order to be considered agile? Should a team do standups to be agile? What if they don’t do standups, does that mean they are not agile, or is it possible to be agile without it? What does it even mean “to be agile”?

This is a topic that comes up every so often without fail. Here are some approaches that are inevitably put forth. I have ordered it in terms of my personal preference, from my least preferred approach to my favourite.

It’s agile if it includes these practices

This school of thought professes a set of practices, like standups or retrospectives, which need to be followed in order to be agile. So, if you aren’t doing retrospectives, then you aren’t agile. The problem with this approach is twofold. First, there are many different agile processes–Scrum, XP, Kanban, FDD, Crystal–and each has its own set of practices, with only very small overlap. So it is hard to nail down a set of practices which MUST be followed. Secondly, there are so many teams that follow ALL the practices, but someone who observes them would not call them agile. Maybe they are co-located, but they dont talk much. Maybe they are developing software incrementally, but rarely release to production and get user feedback.

It’s agile if it follows the manifesto

Another school of though is that it’s not agile if it doesn’t follow the manifesto. Individuals over Process, etc. But there are problems with this approach because it is just too vague. How do you really tell if a team is following the manifesto? The manifesto is a very high level vision statement rather than something actionable where you can go and say, “Yes, this team is following the manifesto”. It can also lead to strange situations, for example a team doing cowboy coding, because the team members just feel like it, would be better aligned to the letter of the manifesto. After all, it is the individuals who have decided to dump the process. But it is hard to think of such a team as being setup for success.

The 7 properties of successful projects

If a set of practices is too constricting, and the manifesto is too vague, then what is the solution?

My guide has been Alistair Cockburn’s excellent 7 properties of  successful projects. Crystal Clear was one of the very first books I read and it made a very strong impression on me, and I’ve been carrying this list around ever since. Unlike other though leaders who are mostly working from anecdotal experience, Alistair’s list comes from specific research into successful projects. Based on this research he identified 4 core properties that most successful projects possess, and 3 additional properties that improve the chance of success, but are not totally critical (ie, it is harder, but possible, to succeed without them).

Here are the 7 properties (top four are the core properties):

  • Frequent Delivery: Do you deliver software to production, at least once a quarter?
  • Reflective Improvement: Do you take time to look back at how you are doing, and where you can improve?
  • Osmotic Communication: Does it take less than an hour to get the answer you are looking for?
  • Personal Safety: Can you give people bad news?
  • Focus: Does the team know what their top priorities are?
  • Easy access to expert users: Does it take less than three days to get an answer from an expert who understands the customer?
  • Strong technical environment: Does the team have automated tests, frequent integration, etc

There are two things that I love about this list.

First, they are outcome based. Take Osmotic Communication for example. Maybe one team might want to make it happen via colocation. Another team might be distributed, but ask all the team members to be online on team chat. Both practices can deliver on the goal: Does it take less than an hour to get the answer you are looking for? Conversely, there may be a team where everyone is sitting together, but they work in isolation without talking. If a team member has a problem, he tries to solve it himself for days without asking anyone. Such a team might be colocated, but they don’t have osmotic communication.

The second thing I love is that it is easy to evaluate. It is not a pie in the sky vision statement. It is specific, and you can easily go to a team and say whether the delivery frequency is good or not, whether communication channels are good or not, etc. It is a great way to figure out where a team stands on the path to agility.

Best of all, it is practice agnostic. This list is applicable whether the team does Kanban, or Scrum, or some custom hybrid.

Categories: Companies

Do You Need an Open Office?

TargetProcess - Edge of Chaos Blog - Wed, 06/25/2014 - 01:10

We’ve been raised in the belief that all humans are social animals, as the theory of evolution has it. If you’re wondering how the evolution and being a social animal is ever related to work in software development, or, more precisely, how it slows down personal and organizational productivity, that’s exactly what my today’s article is about.

Social Animal ≠ Productive Performer

What strikes me most is that we keep on going with the axiom that humans are social animals. Seemingly, we forgot that evolution never stops. With the advances in technology and life infrastructure that happened in the last 30-40 years, the “social animal” concept has suffered some severe cracks. If we look at animals, why are they social? Why they stick together? It helps them feel secure in their natural environment (a flock of deer will sense the danger of the wolves approaching better than one deer), and it helps them get the food easier than on their own (lions, or wolves, hunt in families and then share the meal). Now, do we humans have to gather into a herd, like those animals do in the wild, to secure ourselves or to escape starvation? Obviously, no. But, for some reason, organizations still stick to this thinking as they arrange open-space office layouts for knowledge workers.

Even evolution-wise, the purpose of humans working in an office, to maintain their living, deep down, is no longer to be just fed or to seek shelter. If a contemporary human wants to stay secure and keep “being fed”, the evolution dictates the need to find the optimal ways to perform well at work. “Optimal” stands for “achieve best results with least personal energy consumed”. Staying in physical proximity in one room at work no longer helps our natural evolution, but rather presents a big obstacle to it. With knowledge work, it’s counter-evolutionary and self-sabotaging to expose oneself to the environments that drain us. Numerous research reports prove what people intuitively feel inside:  to keep good health and to perform well, we need to arrange for a space that helps personal productivity, rather than blocks it.

The law of personal energy conservation in the office

Think about it. If you were to count the cases when staying in one room with your co-workers really contributed to your individual performance, and hence to your own well-being and to the well-being of the whole organization vs. how often it was an annoying distraction that sucked your energy that could have been invested into doing the real work? Our co-roomers’ activities have the same effect on us as many apps running in the background have on smartphones. It seems that the phone is doing nothing and just idles, but the battery charge gets lower. The energy is  gone. If you’d need to make an urgent call in the middle of nowhere, with no option to charge it, your smartphone will not be able to accomplish this vital task.

middle of nowhere

It’s about the same with staying in an open-office space. If we throw in to the mixture the other stresses that people have in their lives, things get even worse.

If not an open office, then which one?

How to go about designing office spaces, then? The answer is: it depends on the unique setup and production/development process in your organization. Sometimes sharing a room might work better for a small workgroup, if they rely heavily on a real-communication inside the group.  Like, for a feature team of software developers and QA who call on each other, as they have to verify commits, or if QA’s need help from developers to reproduce a bug, etc.  Or, for customer service employees in technical support and in accounts. It makes sense for them to stay in a shared open-space for their evolution and well-being (read, for their ability to do their work better). However, an open space would be a productivity killer for a strategizer, or for someone who comes up with creative concepts or designs that development teams will then carve in the digital rocks of software. Can you imagine Winston Churchill or Steve Jobs working in an open space office, let me ask? Hardly anyone would doubt that privacy is a must for the highly creative work.

There’s another erroneous consideration that stakeholders might have in mind about open-space offices. They assume that physical proximity will cement people’s belonging to  a cohesive team of individuals who share company goals and values the more, the more time they spend together. Wrong. Belonging to a group can be promoted by other means, such as sharing a company’s philosophy through the space itself, or, what’s most important, by doing some good job together. We wouldn’t think that a family of 4 would have a better sense of a family if they are forced to live in a 200 sq feet apartment, would we? The same is true here. Creating an organizational ethos and having employees light up with it does not happen simply by stowing people in one room. It takes more foresight, thinking and attention to detail. For starters, the team spirit is best promoted by a successful release or by another important milestone achieved together.

This is all about how the specifics of work correlates with the space. While some companies simply do not feel that they can (or should) allocate larger budgets to fine-tune their offices, some people can do just fine working at home, if their home is better conditioned for work than an open-space office. Alternatively, for someone with kids, or with the A/C at home not working, an office would be a better place to work. What and how works better will also depend on the office demographics.  Millenials, the Gen Y-ers, for example, are more likely to put up with the distractions merely due to the fact that they appreciate their office as a space where they can socialize (some say it might be the root cause of why this generation seems to be underpeforming in general). Disclaimer: I’m a Gen X’er :) Not sure if it’s solely for that reason, but I value focused concentration at work more than socializing. This is just another example that shows how deep stakeholders need to think as they approach the job of designing an office. There are so many factors to consider and to write about, that it would take a huge article just to list them all. For each and every company, there will be a unique solution.

Related articles:

5 Things We Need for Sustainable Performance At Work

Continuous Problem-Solving Is No Accident

Getting Closer With Remote

Cognitive Endurance Basics for Software Developers

Top 5 Non-Office Brain Killers

Categories: Companies

Goodbye From the Bobs

Agilitrix - Michael Sahota - Tue, 06/24/2014 - 21:33

(This is goodbye letter shared with the department Paul Heidema and I have been working with for the last few months).

Hi All,

This is a goodbye letter since we are at the end of the main part of project Cocoon.

Why the Bobs?
Someone identified us early on as kinda like The Bobs from Office Space. We like that and think this is really funny.

We hope by now that you see us differently.

We are not here for Agile
If this hasn’t been clear, we are to help you succeed with project Cocoon – which is about re-inventing your department. It’s not about being Agile or using Agile practices. Sure that helps support the goals of Cocoon, but Agile stopped being a goal in April. The goal is helping everyone here be fully engaged and unleashing talent.

Are we Done?
We all wish we had more time. But we don’t. We have made an explicit decision with your leadership team to balance work between tactical, strategic and cultural to best move the needle forward on the Cocoon Vision. We wish we had more time to work with teams, but that would have taken away from sustainable change.

Lasting Change Takes Time
Real and lasting change takes time. It takes everyone working daily to make healthier and more loving interactions.

So sorry, if you were expecting a big TA-DA celebration of success, you are not going to see one. There is a lot of hard work ahead and it takes time to turn the ship around. This is an all-hands type of change.

Keeping in Contact
If you want to stay in touch, you are welcome to connect with us via LinkedIn or email.

When will we be Back?
Paul and Michael will be back together in late August and Michael will be back in Sept/Oct to provide follow-up support.

Happy & Sad
We are so happy to have been able to work with all of you. We are proud of all that has been achieved together. And we are sad to go as we have enjoyed traveling on this road together with you.

You are in good hands
I am glad that you are in good hands. You have a very courageous management team – they are working on themselves first so they can lead by example. And starting to tackle difficult decisions. And of course Corey who has grown so much through this process and enabled all of this to unfold the way it has.


Michael & Paul

Photo: In our support center with Corey

The Bobs

Related posts:

  1. Agile is NOT the Goal (Workshop) Here is how to run a one hour workshop turn...

Related posts brought to you by Yet Another Related Posts Plugin.

Categories: Blogs

Case Studies: Software Systems Failure

Agile Complexification Inverter - Tue, 06/24/2014 - 19:01
Software nightmare stories are very common - but one thing I've learned by listening to these stories over the years is the technologist must be optimist at heart.  Why - because they deal constantly with tons of failure.  And out of those failures they create innovative disruptive new sectors of the world economy (sometimes, case in point the Apple Newton and then the iPod and iPhone).

Let's look at a few case studies:

Time has just published a look at the Obama Healthcare rescue team.  Code Red by Steven Brill

"What were the tech problems?  Where they beyond repair? Nothing I saw was beyond repair.  Yes, it was messed up.  Software wasn't built to talk to other software, stuff like that.  A lot of that,"  Abbott continues, "was because they had made the most basic mistake you can ever make.  The government is not used to shipping products to consumers.  You never open a service like this to everyone at once.  You open it in small concentric circles and expand" -- such as one state first, then a few more -- "so you can watch it, fix it and scale it."
What Abbott could not find, however, was leadership.  He says that to this day he cannot figure out who was supposed to have been in charge of the launch."Or take a look at an Agile/Scrum successful rescue -- the FBI Sentinel case management system.
FBI's Sentinel Project: 5 Lessons Learned by InformationWeek's John FoleyCase Study of a Difficult Federal Government Scrum Project: FBI Sentinel by Michael JamesDoD Goes Agile by Jeff Sutherland DOJ's Report on Sentinel Project by Inspector General - Dec. 2011How the FBI Proves Agile Works for Gov. Agencies by CIO's Jason Bloomberg"Wait, agile rescued a huge money-pit fiasco of a government project? You mean, iterative, skunkworks, put-the-customer-on-the-team, forget-the-plan agile? You betcha. Agile turned out to be the hero in the tights and cape, coming to save the day."
Effective Practices and Federal Challenges in Applying Agile Methods  GAO-12-681: Published: Jul 27, 2012What can one make from failure? Well, author John Kotter of the airport best seller's shelf (Leading Change) created his 8 step model from investigating why companies consistently fail to institute the desired organizational changes that they assumed were mission critical. His conclusion, if they had just done eight things well then the organizational change would have succeeded.
So what can we learn from two of the US governments most recent software project failures?  I think it can be summarized in one phrase - the Big Bang model only works for universes (or God).  The rest of us better learn how to iterate, grow, and evolve systems.

See Also:
Before Scaling up, Consider...
Agile Succeeds 3X more than Waterfall - CHAOS Report 2011 - MountainGoat Software
ObjectMentor success stories:
    Sabre takes extreme measures - ComputerWorld

Categories: Blogs

Success Story: GLG Boosts “Customer Equity” with Assembla

Assembla Blog - Tue, 06/24/2014 - 17:25
GLG Logo Challenge

Garrigan Lyman Group was worried about losing the loyalty of its own customers. The agency was expanding rapidly and tackling more complex e-commerce, mobile, social media and video projects. Clients had no visibility into when new requests would be delivered. Development managers were having trouble tracking releases and matching resources to requirements. Teams needed a solution to prevent missing deadlines and ensure the quality of delivery.


Chris “Whitey” Geiser, GLG’s CTO, knew that the agency could not afford to lose “customer equity,” the hard-won confidence that GLG could deliver innovative digital marketing solutions. So he and his team began looking for technologies that could help them centralize processes, manage development requests, and improve communications with clients.


Assembla has helped Garrigan Lyman Group win new business from existing clients. The solution has helped GLG evolve from helping clients with flashy but self-contained marketing projects, to solutions that work with the core of their businesses. It allows the company to collaborate better with clients and improve control of their development processes.

To see how GLG learned to work more closely with its customers,
fill out the form below to download the full case study.


Categories: Companies

Better Agile Meetings Through Questions

BigVisible Solutions :: An Agile Company - Tue, 06/24/2014 - 17:07

If you happen to be in a meeting with a written objective and agenda, the agenda will have items like “review the plan”. It sounds reasonable. But it is, in fact, very likely to waste your time.

Why? Better Mtgs Thru Questions_BF

Simply, there is no definition of success, so you could talk about the plan for hours and still not accomplish whatever goal was underlying the agenda item. What does success look like for “review the plan”? Do you just put it up on the screen and everyone looks at it? Do you review every task in minute detail? If you define meeting agenda items using questions that specify success, that will help you get
out of this problem and have more effective meetings.

Let’s translate “review the plan” into a few example questions to show you what I mean. I’ve included the meeting objective which is another key piece of meeting success.

Objective: Have a plan that ensures we’ll have enough stories for our team to start work on July 1

  • Will the current plan enable us to have two sprints worth of user stories ready for building by the team by July 1?
  • If no, what do we need to change in the plan to meet that objective?
  • When can we get together as a team to work for an uninterrupted block of time to focus on this work?
  • If the answer is “yes” to the first question, you can move onto the third. When the questions are answered and the objective met, you end the meeting. If the meeting gets off track you can ask “is this discussion pertinent to the question we’re trying to answer?”

    Like any tip for better living (eat more green leafy vegetables) practicing this is harder than reading about it. Try it for two weeks and see what you think.
    (Thanks to David Spann, who introduced me to this idea in his wonderful meeting facilitation course years ago.)

    Want 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 Better Agile Meetings Through Questions appeared first on BigVisible Solutions.

Categories: Companies

LeadingAgile is Hiring Agile Coaches and Consultants

Leading Agile - Mike Cottmeyer - Tue, 06/24/2014 - 13:57

Hey Folks… I’ve never posted anything like this before, but I wanted to let you guys know we are growing and looking for a few top-notch coaches to hire over the next several months. If you are interested, or know anyone that is, please give us a shout.

That said, let me give you an idea of what we are looking for in our ideal agile coach.

1. Our coaches come from a variety of backgrounds so there isn’t really one profile that fits for us. We have folks that have been senior executives in large companies as well as executives in startups. We have people that have started and run their own businesses. We have people that come from a more traditional training and coaching background and we have people with a more traditional management consulting background. The people that tend to work out best for us bring a passion for agile, pragmatism about what agile looks like during a transformation, and a sincere passion for helping people and organizations get better at what they do.

2. As you might expect, you need to be an expert in agile. You should be steeped in the literature and extremely knowledgeable about the entire family of methods. You should be conversant in Scrum and XP as well as Kanban and SAFe. You should know about Crystal, DSDM, FDD, and Lean and where they fit into the body of knowledge. You should have a background applying a wide variety of agile methods in complex environments. You should have the conviction to stand firm on principles but a willingness blend and bend approaches as necessary to help our clients be successful.

3. We need you to be confident and self-assured yet humble with a willingness to learn. While we are not a training company, it would help if you were a gifted trainer full of anecdotes and stories about agile teams you’ve worked with and transformations you’ve lead. You need to be able to hold a room for several days and connect with all levels of an organization. You should be equally comfortable working with a room full of executives as you are with a room full of developers. You’ll often need the ability to speak developer to the business people and business to the developer people. A broad, inclusive perspective is essential.

4.You’ll need to have a strong degree of emotional and social intelligence and have the ability to read a room and adapt your approach to meet the unique needs of the people you are working with. You should have excellent problem solving skills and the cognitive resources to develop customized solutions on the fly, brainstorming ideas with senior leaders in unfamiliar and unique problem domains. You need to be able to work and collaborate with an expert team of coaches, every one of them with strong opinions and unique points of view, and craft solutions that work in the best interests of our clients.

While we strive to find local work for our coaches, if you are not in Atlanta, Washington DC, Orlando, Denver, New York, New Jersey, Los Angeles or San Francisco… you should expect to travel nearly 100%. Local work isn’t impossible to find in other areas, I just wouldn’t count on it. These are the areas where we currently have the most traction or an established client base. That said, even if you are working in your home town, some travel is pretty much inevitable.

You should know that a big part of what we do is probably less coaching and more management consulting. If you are familiar with our approach, you’ll know that we take a pretty hard stance that we have to define a structure, governance, and metrics model as precursor to leading a transformation. We are pretty prescriptive with many organizations, especially early in the process, about how we are going to implement agile. In the complex organizations where we work, playing soft will get us fired. We walk in with a point of view and a plan and a strategy for helping get the transformation started.

In return, we offer a pretty unique environment to work and a very interesting compensation plan.

We are totally distributed but operate in a series of small independent teams we call tribes. Each tribe has all the roles necessary to deliver an account. While you might be flying solo on any particular engagement, you have the support of a complete cross-functional team to share the load. Within the LeadingAgile transformation framework, your tribe has a ton of autonomy to do anything necessary to deliver for the client… you can even ditch the framework if you have to. If we find our approach stops working for us or our clients, we’ll change it. All policy and process is owned by the team we make changes using an open source/committer model.

We are committed to full transparency when it comes to salary, margin, and operating costs, and such within our organization.

We are in the process of moving all our coaches to the same base salary. Each coach has the opportunity to earn an extra 20% of their salary if the company meets certain delivery targets and its a whole team incentive. We are working on a model that can create significant upside for our coaches for certain kinds of sales and marketing activities and we are building a stock option and stock purchase program so everyone has a stake. On occasion we’ve been able to craft unique compensation plans to accommodate special situations where a coach has an established pipeline and/or a proven track record of business development success.

We are definitely a work-in-process and quite often operating way above our WIP limits. If you’re interested in driving meaningful change in large complex organizations, and you want to work for a unique, fast-paced, and innovative early stage growth company… hit us up on the Contact Us page, we’d love to talk. Please make sure to have a resume handy as well as links to anything you’ve posted recently that will give us an idea of what you’re passionate about and how you think.

The post LeadingAgile is Hiring Agile Coaches and Consultants appeared first on LeadingAgile.

Categories: Blogs

A technique to help Prioritise your Backlog

Growing Agile - Tue, 06/24/2014 - 10:00

As a Product Owner do you ever feel that you have too much work and not enough capacity, or have too many stakeholders yelling for their items to be done first? Do you never have time to tackle technical debt or innovation because the head of sales keeps demanding new features?

Prioritising items correctly is one of the difficulties we often see with backlogs. Having a correctly prioritised backlog is valuable though. It ensures that your team is working on the most important items for the business and that your product is headed in the right direction. The most important job you have as a Product Owner is deciding how best to use your team’s capacity.

We have a technique that we teach Product Owners to help prioritise across different stakeholders. The quadrant below shows one way of representing all the possible work that needs to be done on your backlog against 2 axes: time and who the work helps most. In our experience it is easier to get your stakeholders to make an agreement that features to support new customer should only take up 50% of your capacity (for example), than that a particular technical debt item is more important that a particular customer feature. Once you have an agreement of what percentage of capacity to spend on each area (total should be 100%), then you can get stakeholders for each quadrant to prioritise what is the most important way to spend their percentage of the capacity.

PrioritisationSlide A technique to help Prioritise your Backlog

Past and Business (Q1) Here past refers to existing features, or existing clients. Business stakeholders refers to items customers would care about. Items that fall into this quadrant are usually called support items. This might be bug fixes that have been logged by customers, or minor enhancements to an existing feature to make life easier for an existing customer. Items in this quadrant won’t get you new customers, but they will impact on the retention and happiness of existing customers. Also this quadrant is often funded by maintenance and support contracts, so it can in fact be a revenue generating quadrant.

Future and Business (Q2) This quadrant is often the only one people focus on, especially if there is a big drive to get new customers. Items in this quadrant would be anything to help get more customers in future. It could be anything from new features, to scaling, to adding additional platform support for a new type of user.

Past and Technical (Q3) This is an often neglected quadrant. Essentially it is items that exist which impact the technical team. Technical debt is a good example. For example, one feature might be badly written and therefore be very fragile; resulting in bugs each time the team work on this feature. Items here don’t usually bring in revenue, but if selected well they can be great cost savers. Another example in this quadrant might be something that saves the support team a lot of time. For example if your support staff have to debug complex issues, adding additional logging information might be something that will help them reduce the time they spend here.

Future and Technical (Q4) This quadrant is a forward looking quadrant with a technical slant. Often architects can advise on ideas for this quadrant. Potentially a new piece of technology is available that will simplify your product significantly. Other items might be upgrades to existing technology stacks, before the technology you use becomes redundant. For example, upgrading to the latest version of Java. These items can sometimes bring in revenue, because they appeal to customers, but usually these are cost savers, the new technology should make development easier for your team.

BookMB A technique to help Prioritise your BacklogThis is a technique we use in our book “Growing Agile: A Coach’s Guide to Mastering Backlogs”. We have many workshops you can run with your team and Product Owners to help them.

Categories: Companies

Humans suck at statistics - how agile velocity leads managers astray

Software Development Today - Vasco Duarte - Tue, 06/24/2014 - 05:00

Humans are highly optimized for quick decision making. The so-called System 1 that Kahneman refers to in his book "Thinking fast, thinking slow". One specific area of weakness for the average human is understanding statistics. A very simple exercise to review this is the coin-toss simulation.

Humans are highly optimized for quick decision making.

Get two people to run this experiment (or one computer and one person if you are low on humans :). One person throws a coin in the air and notes down the results. For each "heads" the person adds one to the total; for each "tails" the person subtracts one from the total. Then she graphs the total as it evolves with each throw.

The second person simulates the coin-toss by writing down "heads" or "tails" and adding/subtracting to the totals. Leave the room while the two players run their exercise and then come back after they have completed 100 throws.

Look at the graph that each person produced, can you detect which one was created by the real coin, which was "imagined"? Test your knowledge by looking at the graph below (don't peak at the solution at the end of the post). Which of these lines was generated by a human, and which by a pseudo-random process (computer simulation)?

One common characteristic in this exercise is that the real random walk, which was produced by actually throwing a coin in the air, is often more repetitive than the one simulated by the player. For example, the coin may generate a sequence of several consecutive heads or tails throws. No human (except you, after reading this) would do that because it would not "feel" random. We, humans, are bad at creating randomness and understanding the consequences of randomness. This is because we are trained to see meaning and a theory behind everything.

Take the velocity of the team. Did it go up in the latest sprint? Surely they are getting better! Or, it's the new person that joined the team, they are already having an effect! In the worst case, if the velocity goes down in one sprint, we are running around like crazy trying to solve a "problem" that prevented the team from delivering more.

The fact is that a team's velocity is affected by many variables, and its variation is not predictable. However, and this is the most important, velocity will reliably vary over time. Or, in other words, it is predictable that the velocity will vary up and down with time.

The velocity of a team will vary over time, but around a set of values that are the actual "throughput capability" of that team or project. For us as managers it is more important to understand what that throughput capability is, rather than to guess frantically at what might have caused a "dip" or a "peak" in the project's delivery rate.

The velocity of a team will vary over time, but around a set of values that are the actual "throughput capability" of that team or project.

When you look at a graph of a team's velocity don't ask "what made the velocity dip/peak?", ask rather: "based on this data, what is the capability of the team?". This second question will help you understand what your team is capable of delivering over a long period of time and will help you manage the scope and release date for your project.

The important question for your project is not, "how can we improve velocity?" The important question is: "is the velocity of the team reliable?"

Picture credit: John Hammink, follow him on twitter

Solution to the question above: The black line is the one generated by a pseudo-random simulation in a computer. The human generated line is more "regular", because humans expect that random processes "average out". Indeed that's the theory. But not the the reality. Humans are notoriously bad at distinguishing real randomness from what we believe is random, but isn't.

As you know I've been writing about #NoEstimates regularly on this blog. But I also send more information about #NoEstimates and how I use it in practice to my list. If you want to know more about how I use #NoEstimates, sign up to my #NoEstimates list. As a bonus you will get my #NoEstimates whitepaper, where I review the background and reasons for using #NoEstimates #mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; } /* Add your own MailChimp form style overrides in your site stylesheet or in this style block. We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */ Subscribe to our mailing list* indicates required Email Address * First Name Last Name

Categories: Blogs

The Chaos of Leadership or the Leadership of Chaos

TV Agile - Mon, 06/23/2014 - 18:45
Our world suffers from terminal normality. Our world also suffers from too much false expertise, wrong answers, manipulative influence, and bad advice. In this chaos we are taught to make our way to be a success! And we get skewered. Frequently. We’re told to lead, that leadership is influence but those in power, i.e., The […]
Categories: Blogs

Make Product Decisions With A Practical Value Model

Scrum Expert - Mon, 06/23/2014 - 18:38
“Value” is the beacon, watchword, end game, justification, and mantra for Agile practitioners. You make product decisions in Scrum at every turn throughout discovery and delivery, balancing multiple perspectives. And yet, many Agile teams struggle to clearly, concisely, and continually use value as the basis for making product decisions. Ellen Gottesdiener explores a lightweight framework for collaboratively and continually identifying stakeholder values and making value-based decisions on what to build and when. Video producer: Central Ohio Agile Association (COHAA)
Categories: Communities

Retrospectives: A Quick Random Retrospective Generator

Learn more about our Scrum and Agile training sessions on

Thanks to my good friend Deborah Hartmann Preuss for showing me this great tool: Retr-O-Mat – Inspiration (and Plans) for Agile Retrospectives.  It’s a great way of generating a plan for your retrospective if you’re feeling a lack of inspiration!  Includes all five stages of a retrospective: set the stage, gather data, generate insights, decide what to do, and close the retrospective.

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

Cascading Failures vs Robust Code: How SignalLeaf Survived Multiple Crashes And Still Served Podcasts

Derick Bailey - new ThoughtStream - Mon, 06/23/2014 - 13:00

A few weeks ago, SignalLeaf crashed. Hard. The site was down and my error reporting system was reporting an error in the connectivity to the message queue system. My house seemed to be crumbling all around me, and I was in full panic mode.

Collapsed building


At this point, SignalLeaf is averaging around 4,400 podcast episode downloads (“listens”) per day, with spikes near 20,000 a day and peak traffic during daylight hours in the U.S. To have it go down during the daylight hours would be … less than ideal. Or, a disaster. But here’s the thing: in spite of what turned out to be 2 weeks of intermittent crashes and problems, I didn’t lose any important data or have any service outage in serving podcast episodes. All thanks to a somewhat robust architecture. 

A Series Of Unfortunate Events

It started with a network problem between my server and my message queueing service. I spent almost an entire working day babysitting SignalLeaf, restarting it every time it crashed. Sometimes the network between the two services would glitch every 10 minutes. Sometimes it would go for a couple of hours just fine. Eventually, the network issues were resolved and everything became stable again. 

But that’s only where the problems started. A few days later, I started getting more crash reports with a different issue… this time it was database related. Once again, my services were crashing all around me – except for the media service that delivered podcast episodes to people. It was still humming along and serving episodes, in spite of the main website being down.

This time around, it was a database problem. I had forgotten about a small database plan that I was using, and that database plan met it’s limits. Any attempt to write data to it failed, meaning no new episodes could be added, no new accounts, etc. It was, once again, a catastrophic failure on part of the service, but not everywhere. The database problem was solved in a few hours, and things seemed to be stable once again. 

Except “stable” was more like “frozen in time”.

A few days later, one of the podcasters that uses SignalLeaf contacted me to let me know that the reports were not showing any new data for the last few days… the same number of days that it had been since the database issue started. Oh-oh. After a bit of digging around, I figured out that there was a series of cascading failures caused by the database being down for a bit.

I have backup code in place for the times when the queue services is interrupted. This code saves all messages to my database before sending them through the queue. Once the data is processed on the other end of the queue, it’s marked as such in the database and I know I can remove the data. But when the database was having issues, none of these records were being written. The queueing service did it’s job and held on to the messages – near 12,000 of them – but my code was failing when it tired to find the corresponding database record for the message queue message that it was processing. There was no database record for the message. Bam, crash. Ouch.

A few minutes later, I had the queue processing code fixed up to handle that scenario and the 12,000 messages stuck in the queue were processing through. It took about 30 minutes for them to finish processing, and all of the reports on SignalLeaf were back up to date again. 

Did You Notice The Trend, Here?

There were a lot of problems in a short period of time. It was not fun. I spent far too much time babysitting things, but in the process I learned a lot about my code and where it is and is not robust. I also improved the code’s robustness quite a bit in the places that needed it. But through this all, with every failure and every solution, there was one thing that never stopped working: media delivery for podcast listens. 

Quite a while back I decided to split my code in to multiple services, one of which is what I call my media service. This is the service / website that is responsible for serving all “media” (podcast episodes, RSS, etc) to browsers, podcast apps, etc. And while the rest of my services were crashing all around me, there was a core part of the app that was trucking along just fine – the media service. At least, on the surface where the browsers and the podcast apps were concerned, it was still trucking along. I continued to server a few thousand episodes per day, even during the downtime that the rest of SignalLeaf experience.

This was by design, not by accident. It was unfortunate that I had to test this design in production with the rest of my app crashing. But it did prove the design worked as intended. 

Robust, Critical Features

Back when I split apart the code that served episodes from the code that managed everything else, I decided to put a message queue in place. This queue was part of keeping things fast, simple and cleanly separated. It also provided the core of the robust nature that I put in place, in the media services.

With the media services being critical to a podcast media host, I wanted to make sure it would still work as long as my database was able to read data.

During the message queue outage, the media services still worked. They sent episodes to the browser, even though they couldn’t send tracking events to the message queue. The code to send a message to the queue happened asynchronously, after the request for the episode was fulfilled. Serve the episode first, and then try to send the message queue message. 

During the database outage, the media services still worked… I could still read data from the database, but I couldn’t write data. The media services don’t rely on being able to write data. I explicitly made a decision quite some time ago, to allow the database write to fail and still serve the podcast episode. As long as the database can be read, the files can be served. 

By keeping the critical part of my service as simple as possible – I just need read access to the database, to serve episodes – I was able to keep the most important parts of the system up and running while the rest of it crashed and burned around me. The additional features that I want in my system happen outside the critical path. They either have try catch blocks around them, handling the error and serving the file anyways, or they happen asynchronously, allowing the file to be served before the code even runs. 

Improving What Needs It, When It Needs It

Having a good architecture in place allows you to do things like this – to have code that allows failures in some places while keeping other critical things alive. I’m sure my customers were a little less than happy about the main website being down so much, but I’m also sure that they were more than happy to see episodes still being served during that time. Of course I want to improve my code, and I have been. I’ve made improvements every time I run in to a problem, and I will continue to improve things over time. 

But here’s the thing: I don’t think I could predict how the failures that ran in to would affect SignalLeaf, prior to seeing these failures. There are only so many types of failures and specific problems that you can account for, up-front. Yes, experience with problems will give you a bit of a spidey-sense in bad code and architecture, allowing  you to prevent some problems in the future. But there will always be new and interesting ways in which your code will fail. Always. 

The question, then, is not how robust you made the code before you shipped it, but how quickly did you improve the code to prevent that same failure again? How robust is the code now, having faced and survived that particular failure? How much of your system can go down and still allow the most critical part of your system to operate? 

I learned a lot about these questions and answers in the last few weeks of running SignalLeaf, and SignalLeaf is better for it. The code is more robust – it handles an additional set of failures that it previously didn’t handle. The code is now able to handle these failure types without bringing the entire system down. 

And having gone through this, survived and improved my system because of the failures that I experienced, I await the next set of unexpected and panic-inducing problems with a little more confidence in my system’s ability to remain active and in my ability to improve the robustness of the system.

     Related Stories 
Categories: Blogs

The Next 7 Habits of Highly Effective Coaches: Habit 11 – A Good Teacher is a Good Student

Portia Tung - Selfish Programming - Mon, 06/23/2014 - 11:00
Habit 11 – A Good Teacher is a Good Student

An effective coach is an effective teacher. An effective teacher listens. They recognise the needs of the student. They help a student think through a problem by asking open and genuine questions which challenge their assumptions and beliefs.

An effective coach understands the importance of continuous learning, both learning something new or expanding existing knowledge as well as practicing the skill of learning.

Exercise: Get and Give

Ask someone for help or advice. Reflect on the conversation afterwards. Identify what worked well during the conversation then apply one of the techniques the next time someone comes to you for help or advice. Last, but not least, reflect on how effectively you’ve applied what you’ve learned.

For more information, see: The Yellow Brick Road – Insights Through Peer Coaching an Agile Fairytale for learning the 4 key coaching skills of Questioning, Observing, Listening and Feedback.

About This Blog Entry

The Next 7 Habits of Highly Effective Coaches is part of a mini series inspired by the style of Paul Coelho‘s “Manual of the Warrior of Light“. You can find the first 7 habits here.

Categories: Blogs

Recording the Audio Version of the New Book

Scrum Log Jeff Sutherland - Mon, 06/23/2014 - 03:39
The last page of Scrum: The Art of Doing Twice the Work in Half the Time read for the audio version. It took three days of reading to get here:

 The Art of Doing Twice the Work in Half the Time Cover
Pre order now! Available 9/30 from Crown | bn | itunes
Categories: Blogs

Inflexible agility

Doc On Dev - Michael Norton - Mon, 06/23/2014 - 01:29
Back in May of 2014, I attended ALM Chicago. I had the privilege of closing out the conference with my "Let's Start an Epidemic" talk. The second speaker of the day was Venkatesh Rao. This was his third time speaking at the conference and I quickly came to understand why they kept inviting him back. His talk was daring, extemporaneous, and insightful. There were many pearls in his presentation, but one thing he said in particular struck me. And it's popped back into my head time and time again since that day:
It's a special kind of insane to say people over process and then talk about nothing but process. #almchicago @vgr
— Michael (Doc) Norton (@DocOnDev) May 1, 2014 Yet - this is what we do; the "agile community". We say people over process and talk about nothing but process. We debate the merits of XP, Scrum (ala .org or alliance), kanban, SAFe, and DAD. We debate the value of specific practices. Now and then, you'll even hear someone proclaim, "If you are not doing [insert random practice], then you are not agile."

I find it ironic that so many who claim to be agile are so inflexible in their views.

Let's talk about people more than process. Let's focus on individuals and interactions, working software, customer collaboration, and responding to change. Let's figure out how to best achieve these things in our own unique environments. Let's follow the same kind of thinking that lead to these practices so many now hold rigidly to as agile.

The world has changed. The tools have changed. The dynamics have changed. There is more to learn.

Categories: Blogs

Knowledge Sharing

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