Skip to content

Feed aggregator

How architecture enables kick ass teams (1): replication considered harmful?

Xebia Blog - Thu, 07/03/2014 - 12:51

At Xebia we regularly have discussions regarding Agile Architecture? What is it? What does it take? How should you organise this? Is it technical or organisational? And much more questions… which I won’t be answering today. What I will do today is kick off a blog series covering subjects that are often part of these heated debates. In general what we strive for with Agile Architecture is an architecture that enables the organisation to keep moving fast and without IT be a limiting factor for realising changes. As you read this series you’ll start noticing one theme coming back over and over again: Autonomy. Sometimes we’ll be focussing on the architecture of systems, sometimes on the architecture of the organisation or teams, but autonomy is the overarching theme. And if you’re familiar with Conways Law it should be no surprise that there is a strong correlation between team and system structure. Having a structure of teams  that is completely different from your system landscape causes friction. We are convinced that striving for optimal team and system autonomy will lead to an organisation which is able to quickly adapt and respond to changes.

The first subject is replication of data, this is more a systems (landscape) issue and less of an organisational issue and definitely not the only one, more posts will follow.

We all have to deal with situations where:

  • consumers of a data retrieval service (e.g. customer account details) require this service to be highly available, or
  • compute intensive analysis must be done using the data in a system, or
  • data owned by a system must be searched in a way that is not (efficiently) supported by that system

These situations all impact the autonomy of the system owning the data.Is the system able to provide the it's functionality at the require quality level or do these external requirements lead to negative consequences on quality of the service provided or maintainability? Should these requirements be forced into the system or is another approach more appropriate?

Above examples all could be solved by replicating data into another system which is more suitable for meeting these requirements but … replication of data is considered to be harmful by some. Is it really? Often mentioned reasons not to replicate data are:

  • The replicated data will always be less accurate and timely than the original data
    True, and is this really a problem for the specific situation you’re dealing with? Sometimes you really need the latest version of a customer record, but in many situations it is no problem is the data is seconds, minutes or even hours old.
  • Business logic that interprets the data is implemented twice and needs to be maintained
    Yes, and you have to compare the costs of this against the benefits. As long as the benefits outweigh the costs, it is a good choice.  You can even consider to provide a library that is used in both systems.
  • System X is the authoritative source of the data and should be the only one that exposes it
    Agree, and keeping that system as the authoritative source is good practice and does not mean that there could be read only access to the same (replicated) data in other systems.

As you can see it is never a black and white decision, you’ll have to make a balanced decision and include benefits and costs of both alternatives. The gained autonomy and business benefits derived from this can easily outweigh the extra development, hosting and maintenance costs of replicating data.

A few concrete examples from my own experience:

We had a situation where a CRM system instance owned data which was also required in a 24x7 emergency support proces. The data was nicely exposed by a number of data retrieval services. At that organisation the CRM system deployment was such that most components were redundant, but during updates the system as a whole would still be down for several hours. Which was not acceptable given that the data was required in a 24x7 emergency support process. Making the CRM system deployment upgradable without downtime was not possible or would cost .
In this situation the costs of replicating the CRM system database to another datacenter using standard database features and having the data retrieval services access either that replicated database or the original database (as fall back) was much cheaper than trying to make CRM system itself high available. The replicated database would remain running accessible even when CRM system  got upgraded. Yes, we’re bypassing the CRM system business logic for interpreting the data, but for this situation the logic was so simple that the costs of reimplementing and maintaining this in a new lightweight service (separate from CRM system) were neglectable.

Another example is from a telecom provider that uses a chain of fulfilment systems in which it registered all network products sold to its customers (e.g. internet access, telephony, tv). Each product instance depends on instances registered in another system and if you drill down deep enough you’ll reach the physical network hardware ports on which it runs. The systems that registered all products used a relational model which was okay for registration. However, questions like “if this product instance breaks, which customers are impacted” were impossible to answer without overheating CPUs in those systems. By publishing all changes in the registrations to a separate system we could model the whole inventory of services as a network graph and easily do analysis on it without impacting the fulfilment systems. The fact that the data would be a (at most) a few seconds old was absolutely no problem.

And a last example is that sometimes you want to do a full (phonetic) text search through a subset of your domain model. Relational data models quickly get you into an unmaintainable situation. You’re SQL queries will require many tables, lot’s of inefficient “LIKE ‘%gold%’" and developers that have a hard time understanding what a query actually intended to do. Replicating the data to a search engine makes searching far easier and provides more possibilities for searches that are hard to realise in a relational database.

As you can see replication of data can increase autonomy of systems and teams and thereby make your system or system landscape and organisation more agile. I.e. you can realise new functionality faster and get it available for your users quicker because the coupling with other systems or teams is reduced.

In a next blog we'll discuss another subject that impacts team or system autonomy.

Categories: Companies

UI Design in Scrum

Agilecraft - Petri Heiramo - Thu, 07/03/2014 - 10:00

Again, I’ll post an email response to question from an alumni.

The question:

I am working on an agile project and I don’t know when to incorporate prototyping.

The project is a private web application with a number of complex workflows. We have developed high level user stories, but we would like to validate some of the user stories by testing them with a clickable prototype. 

I can approach this a few ways, and I am a little confused. Maybe your advice could help me.

Option 1:  I treat the prototype as part of the user story, as part of the iterative process. I build it into the sprint process and validate it during one of my sprints and iterate from there. 

Option 2: I conduct the prototype work separately before I incorporate it into a sprint and make it part of the discovery / validation process at the beginning of the project. This is how we handled the prototyping for the example I shared. The design/ux team developed and validated the prototype prior to putting the user story into the sprint.

Option 3: A better solution from Petri? :)

To me, both approaches mentioned are valid approaches (what is an invalid approach? One that never works? Anyway…).


I would use option 1 in these two scenarios:

  • The amount of uncertainty is manageable by the team without undue disturbance to other agreed items.
  • All, or most, of team’s work is stories like this. Thus, it is just the natural form of stories for the type or stage of the process, probably an early explorative stage of the product development.
  • There is great haste to moving the item forward, and it is better to commit to uncertain work (and face the consequences) than to spend time learning first.


I would use option 2 when either:

  • There is significant uncertainty about the thing to be done, and the team would not feel comfortable committing to the work as a Sprint story.
  • There are some constraints, like an approval from third party, and that stakeholder is not reliably available for normal sprint work. For example, the appearance has to be approved by Marketing.

Many product programs end up using “two teams” – the development team and the research “team” – that share some of the members. Imagine this as two overlapping circles (which are inside a larger circle – the product). One is focused on developing well-understood stories into Sprint releases, the other is trying to understand what is worth doing. in Scrum terms, the former would be the Development Team, and the latter would be like a Product Owner office (consisting of the PO, some external stakeholders, and some of the team members on a part-time basis).

Both “teams” would have their own flows. The Development Team probably uses something like Scrum, with agreed batches (but they could also use Kanban-like flow), given that the work this team undertakes is probably well understood. The research team is likely to use a Kanban-like flow, given that the work is highly uncertain and there probably are more “balls in the air” at any given time (i.e. there is research work going on in many epics/stories at a given time, and it is not necessarily very clear how long each item will take).

Most Development Team members spend 5-10% of their time in the research team, but some members, like UX designers or domain experts, may spend as much as 50% of their time there. This depends on a given Sprint and will fluctuate as needed. The people must manage their participation in both flows in a responsible way :).

A blog post looking at this model in more detail can be found e.g. from Marko Taipale.


And there is a option 3. It’s not better, just a slightly different approach.

This approach is called “spikes”, “research stories”, or a few other names. It’s kinda like a combination of the two above. Take a research item, write it as a story, and put it into a Sprint. The outcome is a learning outcome, not a product increment. The trick is, these items are not estimated, but timeboxed. In the Sprint Planning, the Team and the PO agree how much time is spent on that item, max (i.e. less time can be spent if a solution is found in that time). When the timebox expires, the team ceases working on that item and reports whatever they learnt in that time in the Sprint Review.

I would use this approach when:

  • The research items are reasonably few in number (like 0-2 per Sprint)
  • There is no “PO office” to handle research
    • Or if there is, but the item is heavily related to the “How”, i.e. technical domain)
  • The PO or the Team want to learn first (in a low-cost way) either about the What or the How, before being able to refine the story further and commit to actual development work.
  • The work can be time-boxed and easily fits inside a Sprint (i.e. there is more development work than spikes in a Sprint).

Getting Agile puts useful additional detail on this option. Also Agile Atlas has a section on this topic.

Depending on circumstances, I might use all three approaches in a project, as appropriate. Each has benefits that some stories would benefit from.

Categories: Blogs

Build Your Own App Specific REPL For Your NodeJS App

Derick Bailey - new ThoughtStream - Thu, 07/03/2014 - 06:24

Nicole Sullivan asked a question on twitter: 

Is there something like rails c or irb in node?

— Nicole Sullivan (@stubbornella) July 3, 2014

I was immediately intrigued by the possibility of having an equivalent of a “rails c” for my NodeJS apps, so I started digging in.

App specific repl

Rails C? IRB? What?

In case you’re not familiar with Ruby on Rails, the idea of “rails c” is that it will open a command line REPL interface with all of your Rails application gems and environment configurations loaded and ready to roll. This is a very powerful tool for debugging and working with Rails apps. I used it A LOT when I was a rails dev.

The “irb” command is the ruby REPL environment, on which “rails c” is built. Of course there is an equivalent of irb in NodeJS: running “node” by itself will open the NodeJS REPL interface. This allows you to run any NodeJS command that you want, directly inside of your console.

Ok, great. NodeJS has a REPL interface that is the equivalent of irb. But what about the rails c equivalent? I don’t know of a built-in equivalent for any NodeJS app frameworks off-hand… but after a few minutes of googling and some trial and error, I found out just how easy it is to build your own application specific REPL interface. 

Build Your Own REPL

It turns out the REPL interface in NodeJS is a module that is built in to NodeJS core, and you can create your own instance of it and play with it to your heart’s content! Check out the basic documentation on the NodeJS site for some quick info on it.

The gist of what you need to do is require the “repl” module and then “repl.start” to start a session. You need to provide a prompt for the start method to use, as well. Let’s use “my-app >” as the prompt.

The result, when you run “node my-repl.js” looks like this:

This is a great start and it shows that you can build your own REPL… but what about customizing it for your application environment?

Customizing The REPL Context

The core of what “rails c” does, other than starting the REPL environment, is loading the application gems and configuration. So let’s do the same thing with our custom REPL for NodeJS and create a REPL that is specific to our application.

The only thing I need to do is attach my application specific modules to my REPL interface. This is done easily by attaching attributes to the “context” object on the REPL object that is returned from the “start” method.

Now when I run my repl.js file, I can instantly access these “context” variables:

Having that in hand, let’s build a custom REPL interface for an application.

Building An App Specific REPL

In my case, I have a lot of custom modules that I built for my SignalLeaf service. These modules include Accounts, Podcasts, amazon integration, and much more. Furthermore, I already have a lot of command-line “reports” that I use for SignalLeaf. These reports each load up the environment configuration, connect to the database and run some code to produce a text based report… and the majority of this code can easily be re-used in my SignalLeaf specific REPL file.

So I’ll take the code that creates my environment configuration variables, requires in all of my app specific modules and connects to the database, then add this to my custom REPL file. I’ll start up my database connection first and once it is connected, I’ll open the REPL session and include all of the custom modules in the REPL context. And for a bit of vanity, I’ll customize the REPL prompt to give me my project name and current environment configuration.

The result is an instant application specific REPL interface, that is now the (close enough) equivalent of a “rails c” console! I can run my application code directly in my REPL interface without having to manually require the modules and instantiate the environment!

Is This Really Useful?

YES! A THOUSAND TIMES, YES! This is a HUGE win for me!

I’ve had countless hours spent in NodeJS console REPL, loading and re-loading all of my app modules. Having this consolidated in to a single file that I can run any time I want, and customize however I need, is an epic win of epic proportions. I will literally save hours of effort every month, as I am now able to load up my entire environment and run any arbitrary code I want, without having to copy and paste a file full of configuration each time I want to do something slightly different and test out some code.




PS: If you’d like to see the NodeJS REPL interface, check out the WatchMeCode video writing your first NodeJS code – it’s the free video that I’ve posted on the homepage of


     Related Stories 
Categories: Blogs

Changing the mindset of Agile teams

Agile World - Venkatesh Krishnamurthy - Wed, 07/02/2014 - 20:35

Recently I penned a guest post for Version One  about the why people behave in the way they do and how to change them ?

Agile is not about practicing Scrum, XP or Kanban. It is a mindset that one needs to cultivate. It is not about doing a daily standup or retrospective but knowing the values/principles behind it. Most of the agile teams are interested in practices and very few are interested to learn the values/principles.

People resist adopting new values and principles as it expects a change in mindset of teams. Changing the mindset of agile teams is always a bit difficult. I have started believing that it is easier to change the people than their mind. The good news is, there are some tools and tips available to help in this journey of changing mindset.

Let me explain one of the tools with an example. A couple of weeks ago, I came across these two dustbins outside of our apartment complex.


As one could see, one of them a simple open cardboard box and the other one is a proper dustbin. Not sure why they had kept these two together. In the next few days, I noticed that people were throwing wastes mostly into the open box. However, the other one needed additional effort to open the lid to throw the wastes, which was left unused.

What I learned from this experience is, if you want people to follow ideas, make it easier for them to learn and use. Or else they will never change.

Another case study is from one of my agile projects. The teams were using an agile project management tool which was not so user-friendly. Teams diligently added all the user stories and tracked them on a regular basis. However, when the need came to extract the key metrics like Velocity and Cycle times, the team had to write queries manually and tweak it regularly. They always resisted this manual, cumbersome process, which was time consuming as well. The teams always used to fall behind sharing these critical agile metrics with the stakeholders.

I suggested an alternate approach, which involved adding a dot on the user story cards after their daily standup until it is complete. It looked something like the one shown in the picture below for measuring the cycle times.  They used a simple sketch pen to put the dots on the cards.  This was so much easier, and the team loved it.  After this little change, they never resisted sharing the metrics.

Conclusion: If you want to change the behavior or mindset of agile teams, create an environment that is easier to navigate and use. The non-intuitive tools and processes could be a major blocker in the change journey of your teams.

Categories: Blogs

Agile Beyond Software: GM Case Study

Agile Management Blog - VersionOne - Wed, 07/02/2014 - 18:23

Car EngineThere is an ongoing debate about whether Agile is just for software or if it can be extended to other industries.  I for one believe the Agile values and principles can be applied beyond software, but, in a recent discussion about this, a colleague raised a concern that some of the principles would be difficult to apply for some industries.  The principle in question: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

The thought here is that manufacturing industries have a high cost for changing once production has begun. This is true, it can be costly to change since production has to be stopped, parts changed, processes reconfigured, delivery would likely be delayed and there is cost in correcting any issues in products already produced.  However, one cost that is often dismissed is the cost of not changing.

Let’s consider the recent case with GM and the ignition switch malfunction.  According to several reports GM has issued a recall on about 2.6 million vehicles to repare the faulty ignition switch.  For arguments sake, let’s just pretend that the cost of the part and the cost to have a post production mechanic replace it is the same as the original.  That means for every replacement, they are paying double the original cost.  Then there are the costs for the accidents caused by the malfunctions, and the biggest cost, the cost of lost lives.  How do you put a price on that?

So, I think we can safely surmise that GM would have spent less money had they replaced the part when they found the issue.  What we should consider next then, is whether they could have replaced it, even late in development.  According to the graphic in this NBC article ( provided by Ronnie Polidoro, GM first found out about the issue in 2001.  Apparently they also dismissed a partial fix in 2005.  Now it’s 2014 and they have finally issued a recall.

It seems clear to me that, in this situation, accepting the change in requirements would have been easier and less costly than going with the chosen path.  It certainly seems that it would have at least been in the customer’s best interest to do so.

What are your thoughts?  Do you think Agile principles could be applied here?  How about Agile beyond software?  I look forward to your comments.

Categories: Companies

Agile Principles - Working Together

Business people and developers must work
together daily throughout the project.
One of the challenges I often face when I start working with a new client that has not been following agile is the amount of time expected from their business people. Their approach has always been that the business people meet with business analyst (BA), tell them what they want, and come back 9 months later to see what got built. 
I have to explain that agile doesn’t work this way and that in order to be successful, we want to have access to the business throughout the project. I find myself providing guidance on how much of business team's time we may need on a daily or weekly basis. 
The real problem with the first (waterfall) approach is that when asked, the business people may not know what they really want. They may be able to come up with a list of things they think they want, but if everything gets built, you will most likely have a lot of features that never get used.
Users will know what they want when they see it. So by starting out with what’s most important to the user, building something to show them, the users can target in on what they really need.
There’s another factor at work here. Studies have shown that a lot of knowledge is lost as it’s handed over from one group to another. So if a BA talks to an end user, creates a requirements document, and hands that to an architect, that architect is going to be missing some of the information the BA learned. When the architect hands it over to a developer, more information is lost. It’s only when all the silos are removed and the developer talks directly to the business person that they get the whole picture. They may hear something that a BA or architect didn’t think was important enough to document that is important. 
This all takes time, which is why a successful agile project follows the principle of the business and IT working together on a daily basis. It is through the interactions that happen on this frequency that help the team know what to really build.
Categories: Blogs

Do You Encourage People to Bring You Problems?

Johanna Rothman - Wed, 07/02/2014 - 13:42

One of the familiar tensions in management is how you encourage or discourage people from bringing you problems. One of my clients had a favorite saying, “Don’t bring me problems. Bring me solutions.”

I could see the problems that saying caused in the organization. He prevented people from bringing him problems until the problems were enormous. He didn’t realize that his belief that he was helping people solve their own problems was the cause of these huge problems.

How could I help?

I’d only been a consultant for a couple of years. I’d been a manager for several years, and a program manager and project manager for several years before that. I could see the system. This senior manager wasn’t really my client. I was consulting to a project manager, who reported to him, but not him. His belief system was the root cause of many of the problems.

What could I do?

I tried coaching my project manager, about what to say to his boss. That had some effect, but didn’t work well. My client, the project manager, was so dejected going into the conversation that the conversation was dead before it started. I needed to talk to the manager myself.

I thought about this first. I figured I would only get one shot before I was out on my ear. I wasn’t worried about finding more consulting—but I really wanted to help this client. Everyone was suffering.

I asked for a one-on-one with the senior manager. I explained that I wanted to discuss the project, and that the project manager was fine with this meeting. I had 30 minutes.

I knew that Charlie, this senior manager cared about these things: how fast we could release so we could move to the next project and what the customers would see (customer perception). He thought those two things would affect sales and customer retention.

Charlie had put tremendous pressure on the project to cut corners to release faster. But that would change the customer perception of what people saw and how they would use the product. I wanted to change his mind and provide him other options.

“Hey Charlie, this time still good?”

“Yup, come on in. You’re our whiz-bang consultant, right?”

“Yes, you could call me that. My job is to help people think things through and see alternatives. That way they can solve problems on the next project without me.”

“Well, I like that. You’re kind of expensive.”

“Yes, I am. But I’m very good. That’s why you pay me. So, let’s talk about how I’m helping people solve problems.”

“I help people solve problems. I always tell them, ‘Don’t bring me problems. Bring me solutions.’ It works every time.” He actually laughed when he said this.

I waited until he was done laughing. I didn’t smile.

“You’re not smiling.” He started to look puzzled.

“Well, in my experience, when you say things like that, people don’t bring you small problems. They wait until they have no hope of solving the problem at all. Then, they have such a big problem, no one can solve the problem. Have you seen that?”

He narrowed his eyes.

“Let’s talk about what you want for this project. You want a great release in the next eight weeks, right? You want customers who will be reference accounts, right? I can help you with that.”

Now he looked really suspicious.

“Okay, how are you going to pull off this miracle? John, the project manager was in here the other day, crying about how this project was a disaster.”

“Well, the project is in trouble. John and I have been talking about this. We have some plans. We do need more people. We need you to make some decisions. We have some specific actions only you can take. John has specific actions only he can take.

“Charlie, John needs your support. You need to say things like, “I agree that cross-functional teams work. I agree that people need to work on just one thing at a time until they are complete. I agree that support work is separate from project work, and that we won’t ask the teams to do support work until they are done with this project.” Can you do that? Those are specific things that John needs from you. But even those won’t get the project done in time.

“Well, what will get the project done in time?” He practically growled at me.

“We need consider alternatives to the way the project has been working. I’ve suggested alternatives to the teams. They’re afraid of you right now, because they don’t know which solution you will accept.”

“AFRAID? THEY’RE AFRAID OF ME?” He was screaming by this time.

“Charlie, do you realize you’re yelling at me?” I did not tell him to calm down. I knew better than that. I gave him the data.

“Oh, sorry. No. Maybe that’s why people are afraid of me.”

I grinned at him.

“You’re not afraid of me.”

“Not a chance. You and I are too much alike.” I kept smiling. “Would you like to hear some options? I like to use the Rule of Three to generate alternatives. Is it time to bring John in?”

We discussed the options with John. Remember, this is before agile. We discussed timeboxing, short milestones with criteria, inch-pebbles, yellow-sticky scheduling, and decided to go with what is now a design-to-schedule lifecycle for the rest of the project. We also decided to move some people over from support to help with testing for a few weeks.

We didn’t release in eight weeks. It took closer to twelve weeks. But the project was a lot better after that conversation. And, after I helped the project, I gained Charlie as a coaching client, which was tons of fun.

Many managers have rules about their problem solving and how to help or not help their staff. “Don’t bring me a problem. Bring me a solution” is not helpful.

That is the topic of this month’s management myth: Myth 31: I Don’t Have to Make the Difficult Choices.

When you say, “Don’t bring me a problem. Bring me a solution” you say, “I’m not going to make the hard choices. You are.” But you’re the manager. You get paid to make the difficult choices.

Telling people the answer isn’t always right. You might have to coach people. But not making decisions isn’t right either. Exploring options might be the right thing. You have to do what is right for your situation.

Go read Myth 31: I Don’t Have to Make the Difficult Choices.

Categories: Blogs

R/plyr: ddply – Renaming the grouping/generated column when grouping by date

Mark Needham - Wed, 07/02/2014 - 08:30

On Nicole’s recommendation I’ve been having a look at R’s plyr package to see if I could simplify my meetup analysis and I started by translating my code that grouped meetup join dates by day of the week.

To refresh, the code without plyr looked like this:

timestampToDate <- function(x) as.POSIXct(x / 1000, origin="1970-01-01")
query = "MATCH (:Person)-[:HAS_MEETUP_PROFILE]->()-[:HAS_MEMBERSHIP]->(membership)-[:OF_GROUP]->(g:Group {name: \"Neo4j - London User Group\"})
         RETURN membership.joined AS joinDate"
meetupMembers = cypher(graph, query)
meetupMembers$joined <- timestampToDate(meetupMembers$joinDate)
dd = aggregate(meetupMembers$joined, by=list(format(meetupMembers$joined, "%A")), function(x) length(x))
colnames(dd) = c("dayOfWeek", "count")

which returns the following:

> dd
  dayOfWeek count
1    Friday   135
2    Monday   287
3  Saturday    80
4    Sunday   102
5  Thursday   187
6   Tuesday   286
7 Wednesday   211

We need to use plyr’s ddply function which takes a data frame and transforms it into another one.

To refresh, this is what the initial data frame looks like:

> meetupMembers[1:10,]
       joinDate              joined
1  1.376572e+12 2013-08-15 14:13:40
2  1.379491e+12 2013-09-18 08:55:11
3  1.349454e+12 2012-10-05 17:28:04
4  1.383127e+12 2013-10-30 09:59:03
5  1.372239e+12 2013-06-26 10:27:40
6  1.330295e+12 2012-02-26 22:27:00
7  1.379676e+12 2013-09-20 12:22:39
8  1.398462e+12 2014-04-25 22:41:19
9  1.331734e+12 2012-03-14 14:11:43
10 1.396874e+12 2014-04-07 13:32:26

Most of the examples of using ddply show how to group by a specific ‘column’ e.g. joined but I want to group by part of the value in that column and eventually came across an example which showed how to do it:

> ddply(meetupMembers, .(format(joined, "%A")), function(x) {
    count <- length(x$joined)
    data.frame(count = count)
  format(joined, "%A") count
1               Friday   135
2               Monday   287
3             Saturday    80
4               Sunday   102
5             Thursday   187
6              Tuesday   286
7            Wednesday   211

Unfortunately the generated column heading for the group by key isn’t very readable and it took me way longer than it should have to work out how to name it as I wanted! This is how you do it:

> ddply(meetupMembers, .(dayOfWeek=format(joined, "%A")), function(x) {
    count <- length(x$joined)
    data.frame(count = count)
  dayOfWeek count
1    Friday   135
2    Monday   287
3  Saturday    80
4    Sunday   102
5  Thursday   187
6   Tuesday   286
7 Wednesday   211

If we want to sort that in descending order by ‘count’ we can wrap that ddply in another one:

> ddply(ddply(meetupMembers, .(dayOfWeek=format(joined, "%A")), function(x) {
    count <- length(x$joined)
    data.frame(count = count)
  }), .(count = count* -1))
  dayOfWeek count
1    Monday   287
2   Tuesday   286
3 Wednesday   211
4  Thursday   187
5    Friday   135
6    Sunday   102
7  Saturday    80

From reading a bit about ddply I gather that its slower than using some other approaches e.g. data.table but I’m not dealing with much data so it’s not an issue yet.

Once I got the hang of how it worked ddply was quite nice to work with so I think I’ll have a go at translating some of my other code to use it now.

Categories: Blogs

Bounce: How to harness your resilience in a changing world

Portia Tung - Selfish Programming - Tue, 07/01/2014 - 22:51
The Challenges We Face

Are you feeling stressed? Do you feel uncertain about the future? Everyday we find ourselves facing different challenges, accomplishing various tasks and constantly adapting.

As mankind has evolved, we’ve become more conscious and informed of who we are and how our minds work. Resilience, previously considered a personality trait, is now a vital modern-life skill which can be developed to help us better deal with everyday challenges as well as great adversity.

My friend Lauren L’ecaros and I have created a brand new 75-minute session to help us all better understand how resilient we are and figure out how to become more resilient in order to overcome our next big challenge.

Check out this presentation complete with speaker notes on Slideshare released under the Creative Commons Share-Alike-By-Attribution licence. Have fun with your colleagues, friends and family:

Bounce: How to harness your resilience in a changing world from Portia Tung Going for Hope

During our search to increase our resilience, we noticed 4 key factors common in helping us tackle our challenges.

We call it the HOPE model.

Help – We can benefit from asking for help as much as giving it
Openness – Being present and daring to be vulnerable with the things we share with others
Perseverance – Never give up. If at first you don’t succeed, try something different
Ease – Strive to perform at your best

Why not give Hope a go?

Categories: Blogs

Abuse of Management Power: Women’s Access to Contraceptives

Johanna Rothman - Tue, 07/01/2014 - 21:19

You might think this is a political post. It is not. This is about management power and women’s health at first. Then, it’s about employee health.

Yesterday, the US Supreme Court decided that a company could withhold contraceptive care from women, based on the company’s owner’s religious beliefs. Hobby Lobby is a privately held corporation.

Women take contraception pills for many reasons. If you have endometriosis, you take them so you can have children in the future. You save your fertility by not bleeding out every month. (There’s more to it than that. That’s the short version.)

If you are subject to ovarian cysts, birth control pills control them, too. If you are subject to the monthly “crazies” and you want to have a little control over your hormones, the pill can do wonders for you.

It’s not about sex. It’s not about pregnancy. It’s about health. It’s about power over your own body.

And, don’t get me started on the myriad reasons for having a D&C. As someone who had a blighted ovum, and had to have a D&C at 13 weeks (yes, 13 weeks), I can tell you that I don’t know anyone who goes in for an abortion who is happy about it.

It was the saddest day of my life.

I had great health care and a supportive spouse. I had grief counseling. I eventually had another child. Because, you see, a blighted ovum is not really a miscarriage. It felt like one to me. But it wasn’t really. Just ask your healthcare provider.

Maybe some women use abortion or the morning-after pill as primary contraception. It’s possible. You don’t have to like other people’s choices. That should be their choice. If you make good contraception free, women don’t have to use abortion or the morning-after pill as a primary contraception choice.

When other people remove a woman’s right to choose how she gets health care for her body, it’s the first step down an evil road. This is not about religious freedom. Yes, it’s couched in those terms now. But this is about management power.

It’s the first step towards management deciding that they can make women a subservient class and what they can do to that subservient class. Right now, that class is women and contraception. What will the next class be?

Will management decide everyone must get genetic counseling before you have a baby? Will they force you to abort a not-perfect baby because they don’t want to pay for the cost of a preemie? Or the cost of a Down Syndrome baby? What about if you have an autistic child?

Men, don’t think you’re immune from this either. What if you indulge in high-risk behavior, such as helicopter skiing? Or, if you gain too much weight? What if you need knee replacements or hip replacements?

What if you have chronic diseases? What happens if you get cancer?

What about when people get old? Will we have euthanasia?

We have health care, including contraception, as the law of the United States. I cannot believe that a non-religious company, i.e, not a church, is being allowed to flaunt that law. This is about management power. This is not about religion.

If they can say, “I don’t wanna” to this, what can they say, “I don’t wanna” to next?

This is the abuse of management power.

This is the first step down a very slippery slope.

Categories: Blogs

Rally’s Colorado Crew Pushes Pedal Power

Rally Agile Blog - Tue, 07/01/2014 - 18:54

In Boulder, Bike To Work Day (BTWD) is a big deal. At Rally, it’s HUGE. This year, as in years past, we went all-out and we played to win. Here are some highlights.

Supporting Bike-crazy Boulder.

Rally is a proud sponsor of Boulder Walk and Bike Month. Our donation from the Rally For Impact Foundation supports Community Cycles, which organizes a dizzying array of bike-related happenings throughout June. It’s so exciting to see our logo alongside those of so many other local businesses on the BTWD posters around town.

Best in Class -- Again!

For the sixth time in seven years, we placed at the top of our class in the Denver metro area Business Challenge. This year, with 300+ employees in Boulder and Denver, we got bumped up to Class D. But we still snagged first place thanks to our effort index of 5.49, with more than 140 out of 330 employees participating -- an impressive 43 percent! We celebrated with a company-provided lunch for cyclists at our new LoDo Denver office, right across from Union Station, and on the patio at our Boulder headquarters.

Pedal Power.

Throughout June, Boulder and Denver employees who biked and walked to work recorded their number of commutes and mileage each week. Our collective total: 4,407 miles! That’s 86 miles farther than the cycling distance from San Francisco to Washington, D.C. 

Spinning for a Cause.

We wanted to cycle with purpose, so we tallied $2 per person, per commute, and donated the total for each week to a nonprofit organization focused on a biking-related cause. The more people who biked, the more the Rally For Impact Foundation donated. All in all, we gave $1,188 to four nonprofits -- each representing a different geography:

Prizes for Participating.

Each week in June we held a (virtual) raffle to give away three $50 gift cards to employees (who earned tickets into the drawing with every walk or bike commute.) In addition, we gave $100 gift cards to the cyclist with the top mileage and most commutes for the month. Chris Driscol was our top mileage winner with 309 miles, and Cameron Holck won the contest for most commutes by cycling 17 out of 18 work days. Both winners selected Boulder Food Rescue to receive $250 donations in their names from the Rally For Impact Foundation.

Going with the Flow.

Our employee biking community used Rally’s team collaboration tool, Flowdock, to stay in touch about all our Walk and Bike Month events -- especially to track how we were doing in the Business Challenge, who was leading the top mileage and commute days categories, and of course, lunchtime rides.

Thanks to everyone who participated, thanks to Rally for supporting the cause, and congratulations to all our raffle and grand prize winners. We can’t wait to do it all again next year!

Angela Tucci, chief marketing officer, and Christine Hudson, solution manager, decked out in Rally jerseys for Bike To Work Day, rode 38 and 32 miles round trip, respectively.

Bike commuters (including me in the green shirt and blue helmet) ready to head home on Bike To Work Day.


More than 100 bikes overflowed Rally’s Boulder headquarters on Bike to Work Day. With plenty of regular bike commuters, Rally offers storage areas and mounted racks inside and outside of the building.

Geri Mitchell-Brown
Categories: Companies

Re-launch of Real Agility Newsletter

Learn more about our Scrum and Agile training sessions on

Hi Everyone!  Berteig Consulting is going to re-launch their monthly newsletter starting this month!  We’re excited about it because, although it is partly due to a legal change around commercial email here in Canada, we are considering this a great opportunity to change the style of our communication with our customers and our colleagues.  Like before, we plan to have a few regular segments:

  1. A message from me, Mishkin Berteig, that shares my personal experiences with Agile, with running an Agile consultancy, and other things that I hope will be interesting.
  2. A “Coaching Corner” article written by one of our coaches, or by a guest author, about how organizations, teams and people can become more Agile.  Topics will range from technical to people-oriented, practical to theoretical, cutting-edge to deeply retrospective.  We hope these articles will become a great resource – and they won’t be cross-posted here on Agile Advice.
  3. A listing of our upcoming training.  We’re excited that in the fall and in the new year we are going to start offering some things besides just ScrumMaster and Product Owner training including training on Agile Coaching, SAFe (and maybe even other enterprise agile frameworks), and topics closely related to Agile such as leadership, communication, etc.
  4. And of course, a “special offers” section that will promote new products or services from us or from close partners that we think will be helpful.

Please subscribe to our Real Agility Newsletter by clicking on the link:


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

Are You Practicing Agile Accountability Responsibly?

Leading Agile - Mike Cottmeyer - Tue, 07/01/2014 - 13:16



I started out this blog post writing about shared accountability for agile program teams. Accountability is an interesting, large topic that gets skipped over quite often in our agile community. In fact, I found, in my writing, a realization that we don’t have a great track record for defining it. So here’s my take.

Caution! I am trying to pair down my mindmap of points to discuss in this blog. Apparently, I am not doing a great job, and I’ll own that. The way that I’ll own it is by committing to write to conclusion about:

•What accountability means to me… as you will find here today
•Exactly what it is at scaled levels of a team… to be written
•How to hold someone accountable… to be written

All right, let’s go for an accountability walk.

If I asked you, “What are teams accountable for?” what would your answer be? Go ahead, and take a minute. Picture the team in your mind. You may want to write it down to refer back to later.

Would your answer include: make and meet commitments, to break down work effectively, or to have a great design or architecture? Would it be to create revenue or an effective marketing campaign? How about “the teams are working hard?”

Definition – Mine, not by the book

Accountable – adj. – A need to explain to an asking authority the actions or decisions made

And in addition,

Responsible – adj. – The state of mind or being that owns the duty of taking care of something or someone

Clearly, there is a relationship to responsibility baked into accountability. The nuances of that relationship are argued over. I am not interested in that argument.

Individual accountability, to me, ideally matches with individual responsibility. That is–in order to be accountable for something–you will want to be responsible for that very same thing as well. Otherwise, you may only be accountable…which would be fine, but it wouldn’t produce the same results that both will.

I love the way Chris Avery describes his responsibility process. This is a very personal process and a great way to understand your own decision-making as to how to move forward toward taking responsibility. If you can move yourself to a responsible state (and, again, Dr. Avery’s work is a great reference), then you can hopefully match up your accountability and responsibility.

I had a unique moment lately when I was running a responsibility exercise with a team that I believed were in a shared denial state–which is really common. Here’s what it looked like:

I gave a set of teams an epic that they failed to deliver and asked them to fill in the following sentence on their own and to not show anyone. I also told them that we would rip up the sheets at the end and they would not have to share the information.

“The epic failed because _____”

I gave them the following choices to fill in the blank.

1. They
2. He
3. She
4. It
5. Me
6. You
7. Us
8. The Business

I didn’t survey the audience, yet I made the following point:

If you are looking at your sheet and you see, “They, He, She, It, You, or The Business,” then you are in a dependent state and not taking responsibility. You have given control to someone else to ensure that you can have a successful outcome. Not a good place because you do not have control of your outcome due to your state of mind.

If you answered, “Me,” then you are at a state of being responsible for your own actions. In this scenario, you have to get the job done and correct the issue.

If you answered, “Us,” then you are at a state of shared responsibility assuming that everyone else that falls under “Us” also answered, “Us.”

Later, I read the classic, “7 Habits of Highly Effective People,” and the idea of dependent, independent, and interdependent relationships resonated the same tone that I was trying to capture. For more info on that just pick up the book. It’s a great read if you are ready for it.

My challenge to the group was similar to the book’s challenge. Basically, if you find yourself dependent, try to move to independent (me), and then consciously try to move to interdependent (us). To do this, you’ll require an inside-out approach. First, you take responsibility and become accountable for yourself to yourself. Then you consciously move the group toward a shared responsibility that matches the accountability of the group. You’ll find that everything doesn’t need to be a shared responsibility, but that’s the goal at the macro or team level. Otherwise, you are little more than the sum of your individual parts.

You may indeed find your team impaired by a lack of organizational enablement. Organizational enablement, to me, implies that teams may not be formed in a way that they can control their own destiny. In scrum, for an individual team, this looks like the team. They may be getting pulled onto multiple teams, have dependencies, etc. In a scaled environment, that includes program and portfolio teams as well. For instance, the program team may not have the architectural capability to support fast release cycles. Many times, I have found that blame has been pushed all the way down to the individual level, and the organization lacks the capability to take responsibility. If this is the case, both managers and subordinates in the dependent state can form a learned helplessness where they are unable to move no matter the incentive because they are not taught to do so. More often, in corporate America, I see it manifest as a complaining, learned helplessness. When agile comes in, we, coaches, bring the therapy couch. However, before we bring the couch, we need to bring the proper structure and governance to enable the helpless and promote a responsible environment. Ultimately, we have always had accountability. Someone always answers to someone else. A clear line of site of the accountability paired with responsibility is a win/win situation for all.

I’ll talk more about what that “win/win” looks like in the future as we discuss what the pull of accountability and the response of responsibility looks like at the team and scaled team levels. For now, I leave you with the need for any team to address how responsible they are being as it applies to how accountable they are being held. If there is a mismatch. find it and march toward responsibility together.

The post Are You Practicing Agile Accountability Responsibly? appeared first on LeadingAgile.

Categories: Blogs

Adding A Category List Page To A WordPress Site

Derick Bailey - new ThoughtStream - Tue, 07/01/2014 - 13:00

Disclaimer: I have no idea what I’m doing when it comes to WordPress development. But I’ve got 4 WordPress blogs (all hosted on DigitalOcean, by the way) and it seems I should know something about this. So every now and then I do something that I think is interesting. This is one of those things. I don’t claim it’s a good idea, but in case it is, I’m telling you how I did it. :)

Cleaning Up A Design

I recently decided to clean up the site. It was cluttered with too many of the typical WordPress things in the sidebars… categories… archives… recent episodes (posts) and more. Frankly all of this content was getting in the way of the site’s purpose: delivering epic quality JavaScript knowledge through screencasts.

So I decided to chop all the side bars out and greatly simplify / clean up the episode pages. I’m glad I did. The end result looks soooooo much better now – super clean.


But after doing this cleanup, I realized that I still wanted a way to show all of the episode categories. This makes it easier for people to find more episodes about subjects they are interested in.

Listing Categories On A Page

After a bit of digging around, and asking on twitter, it was suggested that I use the “wp_list_categories” function:

@derickbailey @curtismchale @pippinsplugins – wp_list_categories should do the trick –

— Eric Fuller (@ericpfuller) June 23, 2014

As it turns out, this is exactly what I needed. But I thought I was going to have to build a custom page template and do all kinds of crazy WordPress things that I have no clue about. Then a little bit later, I realized that I don’t need to do this. I can just add a custom short code and have that short code call this function for me! So I did. And here’s that short code registration / function (all in my functions.php file):

With this in place, I added a new page to my site and just typed in the “show_categories” shortcode and BAMN! Done! now has a nice big list of all the categories, and with a bit of CSS styling, I turned it in to a good looking page where it’s pretty easy to find the categories you’re looking for.


I also added an “Episode Categories” link to the menu so you can easily get to this page. Done.

On WordPress

I’m definitely liking WordPress for my blogs and and sites, still. Things like this may seem a bit obtuse or strange to people (like me) that usually write their own code for this stuff… but I’m ok with that, since it lets me focus on the task of producing content (screencasts and blog posts) instead of producing the website. 

     Related Stories 
Categories: Blogs

What is an Agile Tester? Slides from my Sri Lanka talk.

Henrik Kniberg's blog - Tue, 07/01/2014 - 11:25

Here are the slides for my talk What is an agile tester from the Colombo Agile Conference in Sri Lanka.

What is an agile tester

Competencies over Roles


Agile tester mindset

Categories: Blogs

Agile Manager? What does that mean?

Growing Agile - Tue, 07/01/2014 - 10:00

A tweet yesterday by a client got me to write this post. Here is Maritza’s tweet and a few others we shared.Screenshot 2014 06 18 12.54.41 Agile Manager? What does that mean?

Screenshot 2014 06 18 12.54.55 Agile Manager? What does that mean? Screenshot 2014 06 18 12.55.07 Agile Manager? What does that mean?


Over the last few years the term Agile Manager has become quite popular. My fear was that most of it is for people who where Project Managers and now needed the title Manager but in an Agile environment. However Maritza’s tweet made me stop and rethink this. Maritza is a servant leader Agile Manager. As her tweets suggest, she guides from the side and allows her team to learn and grow without the need to micro manage them every step of the way. So I am sure there are many more Agile Managers out their who are also servant leaders. This makes me super happy!

What is a servant leader anyway?

To me this is someone who leads by example. Someone who sees their job as a leader is to grow people to be the best they can be. This means spending time learning a whole bunch of soft skills like influence, communication, feedback, listening. Let me delve a bit more…


How do you convince people to try something without forcing them? What techniques do you have to influence people who report to you and also to influence those that you report into?


Do your questions encourage people to think and answer? Or are most of your questions looking for a yes/no? How easy and accessible are you to communicate with? How often do you interact with your team socially?


Can you give positive and negative feedback constructively? Is your team able to do this with each other? Does your feedback result in changed behaviour? How open are you to receiving feedback, and do you actively seek it out?


Do you listen to your team? I don’t mean hear them, I mean actively listen, not just wait to have your say. Do your team listen to each other or just talk at each other?

As a servant leader these are the skills you need to learn and pass on to your team. They are not easy. There are no 3 day courses with certification that make you an expert. These take time and practise and experience. The good news is that you immediately see the difference that being a servant leader brings to your team.

We often coach ScrumMasters to develop these skills, but really these are skills that everyone needs. They are more important than me learning the names of rivers in Africa for geography at school. I wish they were taught at school. And I wish everyone who finds themselves in a position of leadership learns them. Perhaps the first step is realising the need to learn these skills.

Categories: Companies

How combined Lean- and Agile practices will change the world as we know it

Xebia Blog - Tue, 07/01/2014 - 09:50

You might have attended this month at our presentation about eXtreme Manufacturing and the keynote of Nalden last week on XebiCon 2014. There are a few epic takeaways and additions I would like to share with you in this blogpost.

Epic TakeAway #1: The Learn, Unlearn and Relearn Cycle Like Nalden expressed in his inspiring keynote, one of the major things for him to be successful is being able to Learn, Unlearn and Relearn every time again. In my opinion, this will be the key ability for every successful company in the near future.  In fact, this is how nature evolutes: in the end, only the species who are able to adapt to changing circumstances will survive and evolute. This mechanism makes for example, most of the startups fail, but those who will survive, can be extremely disruptive for non-agile organizations.  Best example for this is of course Whatsapp.  Beating up the Telco Industry by almost destroying their whole businessmodel in only a few months. Learn more about disruptive innovation from one of my personal heroes, Harvard Professor Clayton Christensen.

Epic TakeAway #2: Unlearning Waterfall, Relearning Lean & Agile Globally, Waterfall is still the dominant method in companies and universities.  Waterfall has its origins more than 40 years ago. Times have changed. A lot. A new, successful and disruptive product could be there in only a matter of days instead of (many) years. Finally, things are changing. For example, the US Department of Defence has recently embraced Lean and Agile as mandatory practices, especially Scrum. Schools and universities are also more and more adopting the Agile way of working. Later more in this blogpost.

Epic TakeAway #3: Combined Lean- and Agile practices =  XM Lean practices arose in Japan in the 1980’s , mainly in the manufacturing industry, Toyota being the frontrunner here.  Agile practices like Scrum, were first introduced in the 1990’s by Ken Schwaber and Jeff Sutherland, these practices were mainly applied in the IT-industry. Until now, the manufacturing and IT world didn’t really joined forces combining Lean and Agile practices.  Until recently.  The WikiSpeed initiative of Joe Justice proved combining these practices result in a hyper-productive environment, where a 100 Mile/Gallon road legal sportscar could be developed in less than 3 months.  Out of this success eXtreme Manufacturing (XM) arose. Finally, a powerful combination of best practices from the manufacturing- and IT-world came together.

Epic TakeAway #4: Agile Mindset & Education fotoLike Sir Ken Robinson and Dan Pink already described in their famous TED-talks, the way most people are educated and rewarded, is not suitable anymore for modern times and even conflicts with the way we are born.  We learn by "failing", not by preventing it.  Failing in it’s essence should stimulate creativity to do things better next time, not be punished.  On the long run, failing (read: learning!) has more added value than short-term succes, for example by chasing milestones blindly. EduScrum in the Netherlands stimulates schools and universities to apply Scrum in their daily classes in order to stimulate creativity, happiness, self-reliantness and talent. The results of the schools joining these initiative are spectacular: happy students, less dropouts an significantly higher grades. For a prestigious project for the Delft University, Forze, the development of a hydrogen race car, the students are currently being trained and coached to apply Agile and Lean practices.  Also these results are more than promising. The Forze team is happier, more productive and more able to learn faster and better from setbacks.  Actually, they are taking the first steps of being anti-fragile.  Due too an intercession of the Forze team members themselves,  the current support of agile (Xebia) coaches is now planned being extended to the flagship of the Delft University:  the NUON solar team.

The Final Epic TakeAway In my opinion, we reached a tipping point in the way goals should be achieved.  Organizations are massively abandoning Waterfall and embracing Agile practices, like Scrum.  Adding Lean practices like Joe Justice did in his WikiSpeed project, makes Agile and Lean extremely powerful.  Yes, this will even make this world a much better place.  We cannot prevent nature disasters with this, but we can be anti-fragile.  We cannot prevent every epidemic, but we can respond in an XM-fashion on this by developing a vaccin in only days instead of years.  This brings me finally to the missing statement of the current Agile Manifesto:   We should Unlearn and Relearn before we Judge.  Dare to Dream like a little kid again. Unlearn your skepticism.  Companies like Boeing, Lockheed Martin and John Deere already did. Adopting XM speeded up their velocity in some cases with more than 7 times.

Categories: Companies

DFW Scrum – Second Quarter Summary

DFW Scrum User Group - Tue, 07/01/2014 - 05:01
Here’s a recap of our meetings for the quarter: April: Definition of Done, Chris Murman Many companies practicing agile talk about the definition of done, but how many teams adhere to it on a sprint-by-sprint basis? Expectations that are either unmet, … Continue reading →
Categories: Communities

What is Capacity in software development? - The #NoEstimates journey

Software Development Today - Vasco Duarte - Tue, 07/01/2014 - 05:00

I hear this a lot in the #NoEstimates discussion: you must estimate to know what you can deliver for a certain price, time or effort.

Actually, you don’t. There’s a different way to look at your organization and your project. Organizations and projects have an inherent capacity, that capacity is a result of many different variables - not all can be predicted. Although you can add more people to a team, you don’t actually know what the impact of that addition will be until you have some data. Estimating the impact is not going to help you, if we are to believe the track record of the software industry.

So, for me the recipe to avoid estimates is very simple: Just do it, measure it and react. Inspect and adapt - not a very new idea, but still not applied enough.

Let’s make it practical. How many of these stories or features is my team or project going to deliver in the next month? Before you can answer that question, you must find out how many stories or features your team or project has delivered in the past.

Look at this example.

How many stories is this team going to deliver in the next 10 sprints? The answer to this question is the concept of capacity (aka Process Capability). Every team, project or organization has an inherent capacity. Your job is to learn what that capacity is and limit the work to capacity! (Credit to Mary Poppendieck (PDF, slide 15) for this quote).

Why is limiting work to capacity important? That’s a topic for another post, but suffice it to say that adding more work than the available capacity, causes many stressful moments and sleepless nights; while having less work than capacity might get you and a few more people fired.

My advice is this: learn what the capacity of your project or team is. Only then you will be able to deliver reliably, and with quality the software you are expected to deliver.

How to determine capacity?

Determining the capacity of capability of a team, organization or project is relatively simple. Here's how

  • 1- Collect the data you have already:
    • If using timeboxes, collect the stories or features delivered(*) in each timebox
    • If using Kanban/flow, collect the stories or features delivered(*) in each week or period of 2 weeks depending on the length of the release/project
  • 2- Plot a graph with the number of stories delivered for the past N iterations, to determine if your System of Development (slideshare) is stable
  • 3- Determine the process capability by calculating the upper (average + 1*sigma) and the lower limits(average - 1*sigma) of variability

At this point you know what your team, organization or process is likely to deliver in the future. However, the capacity can change over time. This means you should regularly review the data you have and determine (see slideshare above) if you should update the capacity limits as in step 3 above.

(*): by "delivered" I mean something similar to what Scrum calls "Done". Something that is ready to go into production, even if the actual production release is done later. In my language delivered means: it has been tested and accepted in a production-like environment.

Note for the statisticians in the audience: Yes, I know that I am assuming a normal distribution of delivered items per unit of time. And yes, I know that the Weibull distribution is a more likely candidate. That's ok, this is an approximation that has value, i.e. gives us enough information to make decisions.

You can receive exclusive content (not available on the blog) on the topic of #NoEstimates, just subscribe to the #NoEstimates mailing list below. 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

Picture credit: John Hammink, follow him on twitter

Categories: Blogs

Knowledge Sharing

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