Skip to content

Feed aggregator

R: ggplot – Don’t know how to automatically pick scale for object of type difftime – Discrete value supplied to continuous scale

Mark Needham - Sun, 07/20/2014 - 02:21

While reading ‘Why The R Programming Language Is Good For Business‘ I came across Udacity’s ‘Data Analysis with R‘ courses – part of which focuses exploring data sets using visualisations, something I haven’t done much of yet.

I thought it’d be interesting to create some visualisations around the times that people RSVP ‘yes’ to the various Neo4j events that we run in London.

I started off with the following query which returns the date time that people replied ‘Yes’ to an event and the date time of the event:

query = "MATCH (e:Event)<-[:TO]-(response {response: 'yes'})
         RETURN response.time AS time, e.time + e.utc_offset AS eventTime"
allYesRSVPs = cypher(graph, query)
allYesRSVPs$time = timestampToDate(allYesRSVPs$time)
allYesRSVPs$eventTime = timestampToDate(allYesRSVPs$eventTime)
> allYesRSVPs[1:10,]
                  time           eventTime
1  2011-06-05 12:12:27 2011-06-29 18:30:00
2  2011-06-05 14:49:04 2011-06-29 18:30:00
3  2011-06-10 11:22:47 2011-06-29 18:30:00
4  2011-06-07 15:27:07 2011-06-29 18:30:00
5  2011-06-06 20:21:45 2011-06-29 18:30:00
6  2011-07-04 19:49:04 2011-07-27 19:00:00
7  2011-07-05 16:40:10 2011-07-27 19:00:00
8  2011-08-19 07:41:10 2011-08-31 18:30:00
9  2011-08-24 12:47:40 2011-08-31 18:30:00
10 2011-08-18 09:56:53 2011-08-31 18:30:00

I wanted to create a bar chart showing the amount of time in advance of a meetup that people RSVP’d ‘yes’ so I added the following column to my data frame:

allYesRSVPs$difference = allYesRSVPs$eventTime - allYesRSVPs$time
> allYesRSVPs[1:10,]
                  time           eventTime    difference
1  2011-06-05 12:12:27 2011-06-29 18:30:00 34937.55 mins
2  2011-06-05 14:49:04 2011-06-29 18:30:00 34780.93 mins
3  2011-06-10 11:22:47 2011-06-29 18:30:00 27787.22 mins
4  2011-06-07 15:27:07 2011-06-29 18:30:00 31862.88 mins
5  2011-06-06 20:21:45 2011-06-29 18:30:00 33008.25 mins
6  2011-07-04 19:49:04 2011-07-27 19:00:00 33070.93 mins
7  2011-07-05 16:40:10 2011-07-27 19:00:00 31819.83 mins
8  2011-08-19 07:41:10 2011-08-31 18:30:00 17928.83 mins
9  2011-08-24 12:47:40 2011-08-31 18:30:00 10422.33 mins
10 2011-08-18 09:56:53 2011-08-31 18:30:00 19233.12 mins

I then tried to use ggplot to create a bar chart of that data:

> ggplot(allYesRSVPs, aes(x=difference)) + geom_histogram(binwidth=1, fill="green")

Unfortunately that resulted in this error:

Don't know how to automatically pick scale for object of type difftime. Defaulting to continuous
Error: Discrete value supplied to continuous scale

I couldn’t find anyone who had come across this problem before in my search but I did find the as.numeric function which seemed like it would put the difference into an appropriate format:

allYesRSVPs$difference = as.numeric(allYesRSVPs$eventTime - allYesRSVPs$time, units="days")
> ggplot(allYesRSVPs, aes(x=difference)) + geom_histogram(binwidth=1, fill="green")

that resulted in the following chart:

2014 07 20 01 15 39

We can see there is quite a heavy concentration of people RSVPing yes in the few days before the event and then the rest are scattered across the first 30 days.

We usually announce events 3/4 weeks in advance so I don’t know that it tells us anything interesting other than that it seems like people sign up for events when an email is sent out about them.

The date the meetup was announced (by email) isn’t currently exposed by the API but hopefully one day it will be.

The code is on github if you want to have a play – any suggestions welcome.

Categories: Blogs

With Me It’s All or Nuthin’

Agile Management Blog - VersionOne - Fri, 07/18/2014 - 21:38

Forgive me for bringing up show tunes.  I love the old musicals. One of the true classics of American all or nothingtheater is the show Oklahoma.  I got to thinking about this in a very roundabout way the other day.  The song, called “With Me It’s All or Nothing” got stuck in my head.  Let me tell you why…

If you like to cruise the various discussion groups, you will find to time see a question “When it comes to Agile practices, which ones should I do first?” or “Which Agile Practice is the most important of all?”  These questions are fun to argue about.  They are mental candy.  But the bottom line is, just like candy, they can also be bad for you.  If we decide that iterative and incremental development is the most important aspect of Agile, does that mean we can get rid of Test Driven Development?  Or, if we decide that Continuous Integration is the most important practice, does that mean we can break out the Gantt charts?  I don’t think it does.

The most egregious example I have seen in this, and it is unfortunately quite common, is the mistaken belief frustrated-programmerthat we can do all of those nifty Scrum ceremonies and activities, and ignore the development practices that make Agile work.  If you have  an iterative process that embraces change, even late in development, but have none of the practices that make that possible, you just have a lot of tired, frustrated programmers. This may be the source of some comments we’ve seen on this blog lately that say “I hate Scrum”.  I often wonder if it is Scrum that these folks hate, or if its the fact that only part of it is being used.

I’ve always seen Agile, or more specifically the implementation of Agile, as a whole package kind of deal.  The real power of Agile software development is not the fact that you do things in smaller increments, orpepperoni and mushroom pizza that you write your code test first, but in the supporting power of each of these elements.  The whole is so much more than the sum of its parts, that I can’t understand why one would chose to not implement the whole thing.  Its sort of like buying a pepperoni and mushroom pizza, then picking off all of the mushrooms.  If you didn’t want mushrooms, why did you order the pepperoni and mushroom?

This all came about because of a rather heated discussion around what is more important, Acceptance Test Driven Development, or Unit Test Driven Development.  The “antagonist” in this argument was contending that since the Unit Tests are “just for the developers” they really were unnecessary, and Acceptance Tests were all that was required.  After a while I couldn’t help but ask “why are we arguing about this?”  The real answer is we need Acceptance Test Driven Development, we need Unit Test Driven Development, Refactoring, Continuous Integration, and yes, Pair Programming.  You see, with me it really is All or Nothing.


Categories: Companies

Why Testing in Women Testers Magazine

Johanna Rothman - Fri, 07/18/2014 - 16:48

I have an article in a new online magazine, Women Testers, the July 2014 edition. My article is called “Why Testing?”

When I was a tester or a developer, I asked many questions. As a project manager, program manager or consultant, I still ask many questions. One of those is the Why question. This article examines that question from a number of perspectives.

Go read that article and many others from people such as Alexandra Moreira, Bolette Stubbe Teglbjærg, Smita Mishra, Sara Tabor, Karen N. Johnson, and Mike Lyles.

I bet you’ll enjoy it!

Categories: Blogs

Project Lessons Learned vs. Sprint Retrospective – 17 Points of Comparison

Learn more about our Scrum and Agile training sessions on

Another fantastic article by Mike Caspar: Sprint Retrospective vs. Lessons Learned (a Generalization)

Mike says:

Consider reviewing these differences in your environment to determine if you are getting benefit from your Sprint Retrospectives and following their intent.


Here are a few other Agile Advice articles about Retrospectives.

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

Enalean announces Tuleap 7 - Thu, 07/17/2014 - 19:09
Enalean, provider of Tuleap, the first Open Source Enterprise suite for Application Lifecycle Management, continues its enterprise quality 100% Open Source strategy by releasing Tuleap 7.This new release provides : Interface overhaul, Agile connector into Eclipse, Git industry-proven performance ...
Categories: Communities

Enalean announces Tuleap 7

Scrum Expert - Thu, 07/17/2014 - 19:06
Enalean, provider of Tuleap, the first Open Source Enterprise suite for Application Lifecycle Management, continues its enterprise quality 100% Open Source strategy by releasing Tuleap 7. New interface When you’ll try or install Tuleap (demo at or free installation at, you’ll notice at first glance that the software gets a new look with an interface overhall : more friendly, easier to use…and that’s just the beginning. For Tuleap 7.0, interface updates have been applied to the artifacts view (tasks, bugs…), charts and agile tools. New Agile Tools Tuleap 7 is much easier ...
Categories: Communities

Do Teams Gel or Jell?

Johanna Rothman - Thu, 07/17/2014 - 18:46

In my role as technical editor for, I have the opportunity to read many terrific articles. I also have the opportunity to review and comment on those articles.

One such comment is what do teams do? Do they “gel” or do they “jell”?

Gel is what you put in hair. When you “gel” things, you create a thick goo, like concrete. Teams are not a thick goo. Teams are flexible and responsive.

Jell is what you want teams to do. You want them firm, but not set in concrete. When teams jell, they might even jiggle a little. They wave. They adapt. They might even do a little dance, zigging here, zapping there.

You want to keep the people in the teams as much as possible, so you flow work through the teams. But you want the people in the teams to reconsider what they do on a regular basis. That’s called retrospecting. People who have their feet in concrete don’t retrospect. They are stuck. People who are flexible and responsive do.

So, think about whether you have a gelled or a jelled team. Maybe I’m being a nitpicker. I probably am. Our words mean something.

If you have an article you’d like to publish, send it to me. You and I will craft it into something great. Whether or not your team jells.


Categories: Blogs

Agile and the Definition of Quality

J.D. Meier's Blog - Thu, 07/17/2014 - 18:06

“Quality begins on the inside... then works its way out.” -- Bob Moawad

Quality is value to someone.

Quality is relative.

Quality does not exist in a non-human vacuum.

Who is the person behind a statement about quality?

Who’s requirements count the most?

What are people willing to pay or do to have their requirements met?

Quality can be elusive if you don’t know how to find it, or you don’t know where to look.  Worse, even when you know where to look, you need to know how to manage the diversity of conflicting views.

On a good note, Agile practices and an Agile approach can help you surface and tackle quality in a tractable and pragmatic way.

In the book Agile Impressions, by “the grandfather of Agile Programming”, Jerry Weinberg shares insights and lessons learned around the relativity of quality and how to make decisions about quality more explicit and transparent.

Example of Conflicting Ideas About Software Quality

Here are some conflicting ideas about what constitutes software quality, according to Weinberg:

“Zero defects is high quality.”
“Lots of features is high quality.”
Elegant coding is high quality.”
“High performance is high quality.”
”Low development cost is high quality.”
“Rapid development is high quality.”
“User-friendliness is high quality.”

More Quality for One Person, May Mean Less for Another

There are always trade-offs.  It can be a game of robbing Peter to pay Paul.

Via Agile Impressions:

“Recognizing the relativity of quality often resolves the semantic dilemma. This is a monumental contribution, but it still does not resolve the political dilemma:  More quality for one person may mean less quality for another.”

The Relativity of Quality

Quality is relative.

Via Agile Impressions:

“The reason for my dilemma lies in the relativity of quality. As the MiniCozy story crisply illustrates, what is adequate quality to one person may be inadequate quality to another.”

Quality Does Not Exist in a Non-Human Vacuum

So many

Via Agile Impressions:

“If you examine various definitions of quality, you will always find this relativity. You may have to examine with care, though, for the relativity is often hidden, or at best, implicit.

In short, quality does not exist in a non-human vacuum, but every statement about quality is a statement about some person(s).  That statement may be explicit or implicit. Most often, the “who” is implicit, and statements about quality sound like something Moses brought down from Mount Sinai on a stone tablet.  That’s why so many discussions of software quality are unproductive: It’s my stone tablet versus your Golden Calf.”

Ask, Who is the Person Behind that Statement About Quality?

The way to have more productive conversations about quality is to find out who is the person behind a specific statement about quality.

Via Agile Impressions:

“When we encompass the relativity of quality, we have a tool to make those discussions more fruitful.  Each time somebody asserts a definition of software quality, we simply ask, “Who is the person behind that statement about quality.”

Quality Is Value To Some Person

Whose requirements count the most?

Via Agile Impressions:

“The political/emotional dimension of quality is made evident by a somewhat different definition of quality.  The idea of ‘requirements’ is a bit too innocent to be useful in this early stage, because it says nothing about whose requirements count the most. A more workable definition would be this:

‘Quality is value to some person.’

By ‘value,’ I mean, ‘What are people willing to pay (do) to have their requirements met.’ Suppose, for instance, that Terra were not my niece, but the niece of the president of the MiniCozy Software Company.  Knowing MiniCozy’s president’s reputation for impulsive emotional action, the project manager might have defined “quality” of the word processor differently.  In that case, Terra’s opinion would have been given high weight in the decision about which faults to repair.”

The Definition of “Quality” is Always Political and Emotional

Quality is a human thing.

Via Agile Impressions:

“In short, the definition of ‘quality’ is always political and emotional, because it always involves a series of decisions about whose opinions count, and how much they count relative to one another. Of course, much of the time these political/emotional decisions– like all important political/emotional decisions–are hidden from public view. Most of us software people like to appear rational. That’s why very few people appreciate the impact of this definition of quality on the Agile approaches.”

Agile Teams Can Help Make Decisions About Quality More Explicit Transparent

Open processes and transparency can help arrive at a better quality bar.

Via Agile Impressions:

“What makes our task even more difficult is that most of the time these decisions are hidden even from the conscious minds of the persons who make them.  That’s why one of the most important actions of an Agile team is bringing such decisions into consciousness, if not always into public awareness. And that’s why development teams working with an open process (like Agile) are more likely to arrive at a more sensible definition of quality than one developer working alone. To me, I don’t consider Agile any team with even one secret component.”

The "Customer" Must Represent All Significant Decisions of Quality

The quality of your product will be gated by the quality of your representation.

Via Agile Impressions:

“Customer support is another emphasis in Agile processes, and this definition of quality guides the selection of the ‘customers.’ To put it succinctly, the ‘ customer’ must actively represent all of the significant definitions of ‘quality.’ Any missing component of quality may very likely lead to a product that’s deficient in that aspect of quality.”

If You Don’t Have Suitable Representation of Views on Quality, You’re Not Agile

It’s faster and far more efficient to ignore people and get your software done.  But it’s far less effective.  Your amplify your effectiveness for addressing quality by involving the right people, in the right way, at the right time.  That’s how you change your quality game.

Via Agile Impressions:

“As a consultant to supposedly Agile teams, I always examine whether or not they have active participation of a suitable representation of diverse views of their product’s quality. If they tell me, “We can be more agile if we don’t have to bother satisfying so many people, then they may indeed by agile, but they’re definitely not Agile.”

I’ve learned a lot about quality over the years.  Many of Jerry Weinberg’s observations and insights match what I’ve experienced across various projects, products, and efforts.   The most important thing I’ve learned is how much value is in the eye of the beholder and the stakeholder and that quality is something that you directly impact by having the right views involved throughout the process.

Quality is not something you can bolt on or something that you can patch.

While you can certainly improve things, so much of quality starts up front with vision and views of the end in mind.

You might even say that quality is a learning process of realizing the end in mind.

For me, quality is a process of vision + rapid learning loops to iterate my way through the jungle of conflicting and competing views and viewpoints, while brining people along the journey.

Categories: Blogs

AGILE2014 conference hosts round-table discussion with leading industry analysts - Thu, 07/17/2014 - 17:12
Agile Alliance, a non-profit organization dedicated to supporting the advancement of Agile software development principles and practices, will host an Industry Analyst Round Table at the AGILE2014 conference, featuring leading research analysts from Cutter Consortium, Gartner Research, IDC and V ...
Categories: Communities

AGILE2014 Conference Hosts Discussion with Industry Analysts

Scrum Expert - Thu, 07/17/2014 - 17:09
Agile Alliance will host an Industry Analyst Round Table at the AGILE2014 conference, featuring leading research analysts from Cutter Consortium, Gartner Research, IDC and VDC Research. The session, titled “Agile Trends and Future Directions,” explores the latest innovations and best practices being deployed within enterprise IT organizations, as well as the latest trends in Agile software development. The research analysts will provide a unique perspective and industry knowledge gained through work with leading vendors and IT organizations. A Q&A format allows attendees to steer the session in directions that are ...
Categories: Communities

Broadening Developer Horizons

Agile Coaching - Rachel Davies - Thu, 07/17/2014 - 16:28

XP is an approach that helps us to deliver valuable software iteratively, to apply it we need to setup our teams to make releasing change to customers as easy as possible. We avoid waiting around for individual team members to make changes, by applying classic XP practices -- Collective Code Ownership and Pair Programming. Each pair of developers is free to change any code that they need to without anyone vetting their changes, they ensure that all tests pass and keep code relatively clean by refactoring as they go. We share knowledge across the team by rotating pairs daily. If a pair runs into difficult decisions regarding design choices, they can call for a huddle with their team mates, sitting together in an open workspace means that's quick to do. This XP way of developing code is liberating as we can easily make changes in the right place rather than working around organisational barriers. It can be also be humbling, as our code is often improved by other developers as they pass through.

To work this way, we find it helps to build teams of extremely capable developers who can work on any area of the codebase rather than hiring a mix of frontend/backend/DBA specialists. Developers who only know enough to work in a single layer of the codebase limit who's available to pair on the piece of work which is most valuable to pick up next. At Unruly, we only hire “full-stack” developers, this gives us confidence that any pair of developers can work on any area of the codebase (within the products that their team is responsible for) without experiencing hand-offs and delays waiting for developers with a different skill set. It also helps avoid some of the friction that can spark due to single-layer thinking.

To make collective code ownership easier, some product teams select a homogeneous stack such as Clojure with ClojureScript or JavaScript all the way down using Node. At Unruly, our developers need to be fluent in JavaScript and Java with a smattering of Scala. Full-stack developers are bright people who can keep pace with developments in multiple languages and frameworks rather than immersing themselves in a single core development language. Being a full-stack developer is more than being able to write code in different languages, you have to understand idioms and patterns for UI, middleware, database realms too.

Being a full-stack developer is also much more than becoming a polyglot programmer. Laurence Gellert’s explains in his blog that there’s a greater breadth of skills that a “full-stack” developer needs. You’ll need to appreciate the environment that your live system runs within and have the technical chops to be at home with making environment changes. You'll also need to broaden your horizons beyond thinking about code and get to grips with developing a fuller understanding of the business you work in! Michael Feathers recently gave a talk in London where he used the term “Full Spectrum Developer” which neatly captures the idea that there's much more than being able to work across different software layers in a given architecture.

As the software craftsmanship movement has brought to the fore, serious developers need to take personal responsibility for improving their skills. Of course, becoming a full-stack developer is mUsing-laptop-on-snowy-mountainore than reading the odd business book in your spare time and writing toy programs in obscure languages when you get home from a long day at work. You can also get together with likeminded developers on a regular basis to hone your skills through Code & Coffee sessions outside work and work on pet projects like building games and mobile apps at home. But in my opinion, this only scatches the surface - you will only get to grips with being a full-spectrum developer by working in an environment that allows you to get your hands dirty across the full stack and interact directly with users and stakeholders. Typically these are startups or small companies that practice agile software development. If you take a look at our current open roles, you’ll see they’re much broader that you’d typically find in a large corporation.

As an agile coach working with product development teams at Unruly, my focus is on how we can support developers to expand their horizons, to gain a better understanding of our business and how they can help figure out the most valuable software to deliver iteratively. Our developers take responsibility for researching different strands of product development and identify the most valuable ideas to take through to implementation (I'll write-up more about how we do this in another post soon).

We also recognise that build learning time into our work week is essential for developers to stay abreast of new tools and frameworks. All of our developers get one day per week to dabble and learn new technologies — see my previous post about Gold Cards. We recognise that industry conferences can be places where you hear about new trends so developers get three days and an annual allowance to spend on attending any conference they feel is relevant to the personal development at work. Our developers also take turns running weekly coding dojos (during work time not through their lunch) to get hands-on practice time with new languages such as Go, Scala, Rust and mobile phone application development. Developers get the opportunity to share what they learned to other teams through lightning talks and this gives them practice in presenting too. All of these things are ways that organizations can support developers in broadening their horizons while at work rather than eating into their early mornings and evenings.

There are a few things for developers to weigh up when considering whether to specialise deeply or broaden their horizons. What do you sacrifice when following one path versus rewards to be gained? The main reward for full-spectrum developers is building greater confidence to dive into different technologies; you may spend less time writing code but become more able to deliver end-to-end solutions that hit the spot. As generalists, you likely have a wider choice of companies to work at and are more resiliant to industry trends. As specialists, you gain the pleasure of total immersion in a particular sphere of software while you build tolerance to the frustrations of waiting around for others to do their bit. It's up to you!

Categories: Blogs

Conventional HTML in ASP.NET MVC: Baseline behavior

Jimmy Bogard - Thu, 07/17/2014 - 16:11

Other posts in this series:

Now that we’ve got the pieces in place for building input/display/label conventions, it’s time to circle back and figure out what exactly we want our default behaviors to be for each of these components. Because it’s so easy to modify the tags generated programmatically, we can establish some pretty decent site-wide behavior for our system.

First, in order to establish a baseline, we need to examine what our current implicit standards are. Right now I’m solely focused on only the input/label/display elements, and not how these elements are typically composed together (label + input etc.). Looking at several of our inputs, we see a prevalent pattern. All of the input elements (ALL of them) have a CSS class appended to them for Bootstrap, “form-control”. Appending this in our normal method of the MVC templated helpers is actually quite difficult and esoteric. For us, it’s a snap.

First, let’s create our own HtmlConventions class that inherits from the default:

public class OverrideHtmlConventions 
    : DefaultHtmlConventions {

We’ll then redirect our container configuration to use this convention library instead:

public class FubuRegistry : Registry
    public FubuRegistry()
        var htmlConventionLibrary 
             = new HtmlConventionLibrary();
        var conventions
             = new OverrideHtmlConventions();

The OverrideHtmlConventions class is where we’ll apply our own conventions on top of the existing ones. The base conventions class lets us apply conventions to several classes of items:

  • Displays
  • Editors
  • Labels

And a couple of things I won’t cover as I’ve never used them:

  • Forms
  • Templates

There’s no real difference between the Displays/Editors/Templates conventions – it’s just a way to segregate strategies and conventions for building different kinds of HTML elements.

Conventions work by pairing a filter and a behavior. The filter is “whom to apply” and the behavior is “what to do”. You have many different levels of applying filters:

  • Always (global)
  • Attribute existence (w/ filtering on value)
  • Property metadata

The last one is interesting – you have the entire member metadata to work with. You can look at the property name, the property type and so on.

From there, your behaviors can be as simple or complex as you need. You can:

  • Add/remove CSS classes
  • Add/remove HTML attributes
  • Add/remove data attributes
  • Replace the entire HTML tag with a new, ground-up version
  • Modify the HTML tag and its children

You have a lot of information to work with, the original value, new value, containing model and more. It’s pretty crazy, and a lot easier to work with than the MVC metadata (which goes through this ModelMetadata abstraction).

I want to set up our “Always” conventions first, which means really only adding CSS classes. The input elements are easy:


Our input elements become a bit simpler now:

@Html.TextBoxFor(m => m.Email, new { @class = "form-control" })
@Html.Input(m => m.Email)

Our labels are a bit more interesting. Looking across the app, it appears that all labels have two CSS classes applied, one pertaining to styling a label, and one pertaining to width. At this point we need to make a judgment call. Do we standardize that all labels are a certain width? Or do we force all of our views to explicitly set this class?

Luckily, we can still adopt a site-wide convention and replace this CSS class as necessary. Personally, I’d rather standardize on how screens should look rather than each new screen becoming a point of discussion on how wide/narrow things are. Standardize, but allow deviation. Our label configuration now becomes:


Then in our HTML, we can replace our labels with our convention-based version:

<div class="form-group">
    @Html.Label(m => m.Email)
    <div class="col-md-10">
        @Html.Input(m => m.Email)
<div class="form-group">
    @Html.Label(m => m.Password)
    <div class="col-md-10">
        @Html.PasswordFor(m => m.Password, new { @class = "form-control" })
<div class="form-group">
    @Html.Label(m => m.ConfirmPassword)
    <div class="col-md-10">
        @Html.PasswordFor(m => m.ConfirmPassword, new { @class = "form-control" })

It turns out in this app so far we’re not using display elements, but we could go a similar path (surrounding the element with a span tag etc).

So what about those other methods, the “PasswordFor” and so on? In the next article, we’ll look at replacing all of the form helpers with our version, based solely on metadata that already exists on our view models.

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

Categories: Blogs

Speaking at Agile2014

AvailAgility - Karl Scotland - Thu, 07/17/2014 - 15:46

Agile 2014

I’m going to be at Agile2014 in Orlando this year – the first time for a few years – and I’m looking forward to reconnecting with lots of people I haven’t seen for a very long time. If you see me, make sure you say “hi!”.

This post is to highlight a couple of things I’ll be doing there, or at least one thing I hope to be doing, and one I’ll definitely be!

First the hope. I’ve submitted a Pecha Kucha on Heuristics for Kanban Thinking, with which I want to introduce the questions asked on the Kanban Canvas. Here’s the description:

This talk will explore how heuristics can be used to frame Kanban Thinking and enable a problem solving capability. I will introduce a set questions which can be used to encourage creative thinking from multiple perspectives, from understanding the problems, to imagining the desired impacts and then designing potential interventions.

Please vote this up to help it get chosen. Otherwise I’ll just have to find another way of talking about the canvas (although I’ll probably run an Open Jam session anyway!).

Secondly, the definite. I’m running a workshop on the Enterprise Agile stage with my friend and former Rally colleague Rachel Weston Rowell. (Its on Tuesday Jul 29, 14:00-15.15 in Osceola A). The topic is Getting the X-Factor: Corporate Planning for the Agile Business. Here’s the description:

The pace of change is accelerating as technology advances, the economy becomes more global and markets become increasingly disruptive. As a result organisations are surviving for dramatically shorter periods of times. For example the average lifespan of organisations on the Standard and Poors 500 index has reduced by over 50 years on the last century, from 67 to 15 years. To survive, businesses need to change the way they operate at a corporate level, as well as becoming more Agile in their delivery capability. This involves moving to a model of co-creating and deploying an evolving corporate strategy, rather than centrally selecting and defining its rigid implementation, in order to create clear alignment, transparency and adaptability.

Join Karl and Rachel as they share the latest learnings from Rally Software’s journey of evolving their quarterly planning and steering. They will introduce one tool they have recently discovered and had positive experiences with, the X-matrix, through which strategy deployment can be achieved. This is a simple, single A3 page format, which visualises the correlations and contributions between strategies, tactics, improvements, results and departments. In this session you will work through completing an X-matrix for an example organisation.

Please come along! We ran this at RallyON, got great feedback, and had a lot of fun.


Categories: Blogs

Scrum Sprint Planning is Shopping Time !

Agile Thinks and Things - Oana Juncu - Thu, 07/17/2014 - 08:27
"Throw a purpose in the middle of the group, it starts to self-organize" - Michelle Holliday at CultureCon , Boston 2014.I do believe The secret of Agile magic dynamics is its purposeful mindset: every practice is organized to sustain the one thing : creating a product ( eventually software) at a regular pace, whose usefulness is validated at the same pace. Scrum calls this pace a sprint. Because the inner motivation of each individual, team or organization is given by the validated usefulness of what is delivered by each individual, team or organization, the demo at the end of the sprint is fundamental. So better make it truly entertaining.  The other cool tip of Scrum product development is the sprint planning, a thrilling moment where we'll plan how exciting the story of the new product will be at the end of the sprint.Sprint Planning - Back to Basics There are no simpler game rules than those of  the  sprint planning in an software product development context : the development team tells how many story points they can address during the sprint. The Product Owner picks her favorite user stories ( well favorite means with the highest Business Value ;) ) for a total amount of story points that fits the number given by the development team. That's all . Sprint planning is like shopping : the Product Owner can do some favorite User Stories Shopping in the Backlog Store for the amount of Story Points credited by her development team. Ain't that a cool plan ? I think it is! So why so many teams struggle with this ?
Sprint Planning Is NOT Estimation PlanningMany Scrum teams  seem to suffer the lack of a light purposeful - from an User Experience perspective -  version of backlog , that can be enriched in respect with the feed-back from different
users and stakeholders, the changes in strategy , the zoom-in in details and specific scenarios. This leads often to an unclear stack of User Stories , eventually not very user centric. Often the confrontation with the backlog takes place at the sprint planning time, when the development team performs aka "emergency estimation" that enables to plan some-work-no-matter-what,  for the next sprint . This "emergency" approach is exhausting , the session may take hours and everyone has only one dear wish : to get over with it!  I even wonder if the noEstimates  movement didn't rise from the legitimate despair of some participants in such sprint planning sessions .
The story of sprint planning worths some rewriting , based on a key rule : there is no user story
estimation during the sprint planning . As an Agile team ( ie a product centric team) do whatever it
takes from product envisioning to story mapping to have a fluent Backlog Story. Then , if Planning Poker sessions need to be hold, those are to be planned during the sprint, in respect with their business value and the alignment with the product vision ( ie Purpose) .  These sessions are generators of  insights and synchronisation opportunities among all members of a team. These insights cannot be achieved under sprint start time constraints.
NoEstimates And The Pleasure of Shopping TimeThe movement and the approach of  NoEstimates is highly interesting and revolutionary. Basically , it states that anything need to be spent to deliver what has the most important Business Value , why should people waste time to estimate that most important work.  While I fully agree with the mindset of noEstimates, I always found planning poker sessions a great token for discussion among
development team members that empowers a shared understanding of what needs to be done.
And it would be a pity to loose the excitement of  the "sprint planning shopping time"  for the next
"demo party "  where the product team prepares  what the new adventures of the users of the new product will be ,  how the  the new blast quality of the code can be shown in the demo and ... what type of cookies will be served at the demo time to customers ( why not ! )
Related postsWhy Agile Incremental Development Hooks Us
Story mapping tells the story of Your Product
Demo Driven Development 

Categories: Blogs

Skip Angel talks about Self-Organizing Teams at Agile 2013

BigVisible Solutions :: An Agile Company - Thu, 07/17/2014 - 01:10

The development team is the heart and soul of agile. If you have highly productive teams that can understand and focus on delivering value for their organizations, you will see great results. But if your team is a group of individuals only focused on their own personal goals in a highly dysfunctional environment, implementing agile will be much more difficult and painful.

The post Skip Angel talks about Self-Organizing Teams at Agile 2013 appeared first on BigVisible Solutions.

Categories: Companies

The Silver Bullet for Productivity Discovered

TargetProcess - Edge of Chaos Blog - Wed, 07/16/2014 - 21:18

I’m subscribed to a newsletter from Buffer, a startup softdev company that develops an app to manage multiple social accounts. It’s quite an unusual thing for a social media-related company to share sensible advice in their newsletter, and that’s the reason I wanted to learn more about that company. So, I googled all things Buffer. The more I researched, the more I admired them. They are a startup, and they do well, generating over $3 mln in annual revenue, with only 23 people.  What is the reason for such an amazing performance? How have they been able to grow from zero to a revenue-generating company, in 3 years, with a lean squad of people, and still bootstrapped? How do they keep up their productivity?

The answer came with a little bit more of research. Buffer don’t wrap their rules of operation in the toga of productivity, or agile, or development process lingo, which is very unusual, and which might explain why this company performs way better compared to the others that do. What’s more, Buffer keeps their people happy and emotionally fulfilled.  They don’t think of their company as a racing car that has to be ramped up on speed. They, actually, are not concerned with productivity, or speed, for that matter, at all. The point is: Buffer spotted this one bottomline thing that powers productivity. They refer to their rules of operation not as to policy, but as to culture. And, the way I see it, the ultimate key to their performance is one simple thing called clarity. Check this snip from Buffer’s culture statement.

clarity at Buffer

It might be hard to believe at first, but with a little bit of thinking, we will see that clarity is the key to productivity for any team’s work. Thinking logically, a team’s performance is a sum of smooth individual flows and actions. Developers write code, QA engineers do testing, someone is in charge of automated tests, designers do all things UX. Now, when productivity suffers? As with cars and highways, stops occur when there’s a roadblock or a speed bump of something not being clear. What happens if bumps accumulate for weeks, even years? Production team lose track of priorities and incentives, if a day’s work is filled with  un-clarity every step along the way. What should I do in this case? Who do I contact? Who has a clue to this problem that I have? If people in the team fill most of their days with these questions, it’s time to put up a huge red flag and “beware bumps” sign. In this sad case, the team is deprived of the very chance to perform, even if they want, because, individually, they lack clarity. They need to have a clear knowing of those “who, what, why, when, how”-s related to their work, or, at least, they need a fast and smooth way to get the answers. If finding an answer for a repeated daily task becomes an ad hoc improvised quest, R.I.P.  productivity. The things covered under the umbrella term of  “efficient development process”, are rooted in crystal clarity.

Clarity is also crucial when it goes about motives for the actions of others. Second guessing, or a misunderstanding about someone doing things the way they do them, is another severe case of un-clarity. Generally, we are supposed to assume that everyone is doing their job as best as they can, but, with lack of clarity, the thing  that I call “assuming dumbness” rears its ugly head. When it happens, instead of having it clear why someone  in a team has done a code, or a test, or a copy, or a design in exactly that way, others make a default assumption that this person is “dumb”, not competent and not knowledgeable. This isn’t a productivity killer, per se, but it is a dangerous team spirit killer, and I hope you haven’t spotted this in your team.

As we can see, there’s no need to go any further and re-invent the wheel. If you’re concerned about bad productivity, or if you see that people look exhausted, unhappy or loose, seemingly giving up on their work, they crave for someone to champion clarity. That’s what Buffer calls “Default to transparency“, which is a sibling of clarity.

default to transparency

So, ask yourself, do you always have this clarity? In your team? Is your day made up of roadblocks, or is it filled with gratifying work which goes in a seamless flow? If no, take action. Go for clarity. Demand it from your managers. Clarity is this so much wanted silver bullet for productivity in a software development team. If you find ways to instill the culture of clarity in your team, every step along the way, the Holy Grail is yours.

Related articles:

Non-Violent Communication for Agile Teams

Are You Dumb?

How Communication Factors In To Production

Non-Judgmental Communication for Agile Teams

Why Fast Is Slow

Uselink: Organizational Culture and Development Process

Project Manager or Tech Leader?

The Dangers of Small Talk

Why Self-Organization Is a Luxury

Why Is It Right to Write?

What’s Wrong With Your Questions?

When Intensity Pays Off

Categories: Companies

The Last Job on Earth: Part IV

Indefinite Articles - John Brothers - Wed, 07/16/2014 - 20:00

So, hopefully at this point I’ve established that computer programming and understanding the law and the legal process are somewhat similar.

And that understanding the legal process without tremendous amounts of specialized knowledge is incredibly difficult.

And hopefully I’ve convinced you that the claim that “Everyone can code” is far, far too simplistic, given the tremendous amount of domain knowledge involved.

But let’s add another claim:  programming is a form of art.    Sure, it’s a form of engineering.  But Stonehenge was also the output of engineering, and yet we recognize now that there is beauty and art involved in Stonehenge, not just engineering.   Even the Mona Lisa involved modest amounts of engineering:  the viscosity of the paint, the pressure of brush upon canvas, the manufacture of the canvas itself.   All of those things are engineering disciplines.   But the output was far more meaningful than the engineering involved.

When you start a software project, it is often an exceptionally wide-open field.  You may have some constraints, some requirements, but significant portions of the work to be done are undiscovered.

There’s an old story about how to create a statue of an elephant.  You take a block of stone, and you chip away everything that doesn’t look like an elephant.   That’s deceptively simple, isn’t it?   Really, the art isn’t in the chipping, it’s in the recognition that bits and pieces are starting to look like an elephant.     In many ways, building software is taking a big empty block of “all possible solutions”, chipping away to remove things we don’t want, adding more to fill in parts we do want, until there’s nothing left but the system we want (or the customers want).

Just like sculpture, software is a creative process.







Categories: Blogs

Kanban: Redefining the Importance of Process Policies

Setting explicit process policies is the special sauce for the successful implementation of Kanban. Yet in many ways it’s also the least understood step of The Kanban Method. For many people, the term “policies” conjures up images of employee manuals and handbooks. And let’s be honest, while these types of organizational documents are necessary, they’re […]

The post Kanban: Redefining the Importance of Process Policies appeared first on Blog | LeanKit.

Categories: Companies

Are You Doing Portfolio Management, or Issuing Hunting Licenses?

Rally Agile Blog - Wed, 07/16/2014 - 16:46

Do you have a set of budgeting, funding, and approval processes so complex that nobody knows how they all work? Is the easiest way to get something done at your company to escalate to a senior executive, or go straight to a developer?

The other day, I was helping a customer untangle their approval/funding/budgeting processes. Now, this may not sound like the most delightful afternoon, but it was hot outside, and we were all ready to do it.

The company already has adopted some parts of SAFe -- they’re doing mid-range planning once per quarter in a big meeting, and getting better and better at delivering on those plans. But invariably, a half-dozen program managers and stakeholders would appear at those meetings wondering why their budget-approved projects weren’t in the backlog.

As it turned out, the budgeting and approval process was pretty Lean already -- but it was completely disconnected from PSI planning.

A small group of people was great at validating new business opportunities, rapidly exploring them, and deciding whether to fund them, all in a matter of hours or days. Once a project got approved, the project manager was then free to go off and try to get resources allocated -- either hiring people, or getting them reassigned, or just peeling off 20% of their time.  

This approach was a relic from the old waterfall ways of working. We’ve all seen these resource battles, and I realized on that hot afternoon that this wasn’t just a benign approval process.

Beware the Resource-management Jungle

This process was granting hunting licenses.

That is, project and program managers were heading out to figuratively hunt for people to enlist on their projects.

Are you doing this? Are you doing a careful job of approving work, only to send people off into a resource-management jungle armed with nothing but a budget, a business case, and a set of relationships?

If so, you might find that there’s a lot of wacky resource contention going on. You might even find people caught in the crossfire as project managers compete to capture their resources. (Is that the elusive senior engineer? Trap him in your team room! Promise him free lunches if he stays!)

Prioritize Your Backlog

So, what’s the alternative? It’s actually quite simple. The approval process has to feed into a backlog of initiatives. You’ve got to get your senior leaders to prioritize these initiatives based on your planned spend in different investment themes. This prioritization then feeds the backlog of work that goes into your mid-range planning meeting.

Then, when your teams actually plan out the work, you can see whether they’re actually working on your top priorities and adjust accordingly.

When you start your project depends on its priority, but it also depends on the number of initiatives you’re already working on (your WiP, or Work in Progress). Just because your initiative is approved doesn’t mean it should start right now.  

If the wait to start a new project is too long, that’s just a clear sign that you’re already working on too many things at once.

So your approval process shouldn’t grant a license to hunt resources. Project approval doesn’t mean you’re authorized starting the work immediately. It just means, “This thing seems like a good enough idea that we should prioritize it against all of our other opportunities.”

Modern Agile portfolio management suggests using the team as the resource unit. Read more about it here.

Alex Pukinskis
Categories: Companies

Lots of carryover? Try swarming

Agile Management Blog - VersionOne - Wed, 07/16/2014 - 16:15

swarming4Scrum teams are made up of individuals with cross functional skills that commit to completing the sprint backlog as a team. Instead of a traditional Project Manager assigning tasks, the team decides how they are going to get the work done and individuals choose or sign up for the work they want to do.

If on sprint planning day, the team determines the owner for every task, then it’s very easy for our introverted development teams to go heads down at their desk and only focus on their personal ‘to do’ list. Even though they are having a daily stand up, if they are not truly paying attention to how the team as a whole is tracking according to their plan, then teams can end their sprint with several backlog items partially completed. The team has to own up to the stakeholders during the sprint demo that they didn’t meet their commitment and that walk of shame is no fun. Plus, a backlog item that is 90% complete does not make the company money so the team discusses in the retrospective how to prevent that from happening again.

I would challenge a team who finds themselves in this situation to no longer determine the owner of tasks on sprint planning day. Instead, allow team members to sign up for a task daily throughout the sprint following the swarming approach. Like when worker bees swarm together to build a new hive, teams should swarm together to work down the prioritized sprint backlog. On the first day of the sprint, the team should put only the top backlog item in progress until it meets the definition of done. Once the top backlog item is done, then the next backlog item in the list can be put into progress. Based on the size and skill sets of the team, they may find that their WIP limit is two to make sure everyone has a task on the first day of the sprint. To help enforce this, the team can set a WIP limit of one or two on the ‘In Progress’ column of their story board. This focus will:

  • Keep the team working together closely and will result in less context switching
  • Keep the intensity level high on getting impediments resolved ASAP
  • Forces the team to test early in the sprint instead of it becoming a bottleneck at the end
  • Product Owner can provide feedback, verify and accept a backlog item early in the sprint instead of on the last day

The Product Owner who has three backlog items done and accepted feels a lot better than the Product Owner who only has seven items that are 90% complete.

Categories: Companies

Knowledge Sharing

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