Skip to content

Feed aggregator

5 minutes on regulations – wie gute Prozesse in der Medizintechnik Innovation verhindern

Scrum 4 You - Mon, 09/01/2014 - 07:30

Ich hatte letztens das Vergnügen, drei Stunden Einführung in RUO und IVD Regulatorien zu bekommen. RUO steht für “Research Use Only” und IVD für “In Vitro Diagnosis”.[1] Diese strengen Richtlinien der FDA (Food And Drug Agency) beschreiben, was ein Hersteller vorweisen muss, damit die FDA seine Produkte auf dem amerikanischen Markt zulässt.

Ich kann hier gar nicht auf all das eingehen, was gefordert wird, aber ich habe zwei Zahlen für euch: Für ein RUO-Produkt – also eines, das nur für Forschungszwecke herangezogen werden darf – müssen ungefähr 2500 Seiten Dokumentation an die FDA geschickt werden, auf denen sorgfältig festgehalten wurde, wie dieses Produkt funktioniert. Ein IVD-Verfahren verlangt ungefähr 10.000 Seiten Dokumentation.

Das aber in Wahrheit Merkwürdige: Wer ein IVD-Produkt einreichen will, muss nachweisen, inwieweit dieses Produkt im Vergleich zu einem bereits bestehenden Produkt besser ist. In irgendeinem Faktor. Es wird also nur etwas Neues mit etwas Altem verglichen. Wer etwas noch nie Dagewesenes erfindet, muss sich also mit der FDA darüber einigen, wie man damit umgehen will.

Okay, das ist noch alles irgendwie verständlich. Es geht um das Leben von Menschen und da müssen Fehler so weit als möglich vermieden werden. Aber jetzt wird es noch faszinierender: Angenommen, man hat die Zulassung und will etwas am Gerät verändern – sagen wir, das User Interface der Adminoberfläche eines computerunterstützten Produkts. Dann könnte es passieren, dass alle 10.000 Seiten erneut eingereicht werden müssen. Ach ja, das Ganze kostet ca. 250.000,- US Dollar.

Sicher, wer will entscheiden, ob es nur eine kleine, unbedeutende Änderung ist, oder eine mit schwerwiegenden, vielleicht noch nicht absehbaren und möglicherweise tödlichen Folgen. Aber was sich damit natürlich wie von selbst erledigt, ist Innovation. Innovation findet, wie wir spätestens seit dem Buch „The Innovator’s Dilemma“ wissen wissen, am Rand – “in the fringe” – statt. Da, wo es noch keine großen Gelder gibt. Da, wo noch nicht klar ist, wie etwas funktioniert. Es zeigt sich im Kleinen.

Prozesse wie jene der FDA sind notwendig, keine Frage – doch wir brauchen intelligente Antworten darauf, wie wir diese Anforderungen erfüllen. Wir brauchen diese Antworten, weil wir auch in der Medizin noch viele Probleme lösen müssen.

[1]“In vitro diagnostic products are those reagents, instruments, and systems intended for use in diagnosis of disease or other conditions, including a determination of the state of health, in order to cure, mitigate, treat, or prevent disease or its sequelae. Such products are intended for use in the collection, preparation, and examination of specimens taken from the human body. [21 CFR 809.3]” Mehr Information dazu hier

Related posts:

  1. Tuberculosis – The pandemic of the 19th century is back?
  2. Der Product Owner / Story Writing
  3. Mit Agil richtig dokumentieren

Categories: Blogs

R: ggplot – Cumulative frequency graphs

Mark Needham - Mon, 09/01/2014 - 00:10

In my continued playing around with ggplot I wanted to create a chart showing the cumulative growth of the number of members of the Neo4j London meetup group.

My initial data frame looked like this:

> head(meetupMembers)
  joinTimestamp            joinDate  monthYear quarterYear       week dayMonthYear
1  1.376572e+12 2013-08-15 13:13:40 2013-08-01  2013-07-01 2013-08-15   2013-08-15
2  1.379491e+12 2013-09-18 07:55:11 2013-09-01  2013-07-01 2013-09-12   2013-09-18
3  1.349454e+12 2012-10-05 16:28:04 2012-10-01  2012-10-01 2012-10-04   2012-10-05
4  1.383127e+12 2013-10-30 09:59:03 2013-10-01  2013-10-01 2013-10-24   2013-10-30
5  1.372239e+12 2013-06-26 09:27:40 2013-06-01  2013-04-01 2013-06-20   2013-06-26
6  1.330295e+12 2012-02-26 22:27:00 2012-02-01  2012-01-01 2012-02-23   2012-02-26

The first step was to transform the data so that I had a data frame where a row represented a day where a member joined the group. There would then be a count of how many members joined on that date.

We can do this with dplyr like so:

> head(meetupMembers %.% group_by(dayMonthYear) %.% summarise(n = n()))
Source: local data frame [6 x 2]
  dayMonthYear n
1   2011-06-05 7
2   2011-06-07 1
3   2011-06-10 1
4   2011-06-12 1
5   2011-06-13 1
6   2011-06-15 1

To turn that into a chart we can plug it into ggplot and use the cumsum function to generate a line showing the cumulative total:

ggplot(data = meetupMembers %.% group_by(dayMonthYear) %.% summarise(n = n()), 
       aes(x = dayMonthYear, y = n)) + 
  ylab("Number of members") +
  xlab("Date") +
  geom_line(aes(y = cumsum(n)))
2014 08 31 22 58 42

Alternatively we could bring the call to cumsum forward and generate a data frame which has the cumulative total:

> head(meetupMembers %.% group_by(dayMonthYear) %.% summarise(n = n()) %.% mutate(n = cumsum(n)))
Source: local data frame [6 x 2]
  dayMonthYear  n
1   2011-06-05  7
2   2011-06-07  8
3   2011-06-10  9
4   2011-06-12 10
5   2011-06-13 11
6   2011-06-15 12

And if we plug that into ggplot we’ll get the same curve as before:

ggplot(data = meetupMembers %.% group_by(dayMonthYear) %.% summarise(n = n()) %.% mutate(n = cumsum(n)), 
       aes(x = dayMonthYear, y = n)) + 
  ylab("Number of members") +
  xlab("Date") +

If we want the curve to be a bit smoother we can group it by quarter rather than by day:

> head(meetupMembers %.% group_by(quarterYear) %.% summarise(n = n()) %.% mutate(n = cumsum(n)))
Source: local data frame [6 x 2]
  quarterYear   n
1  2011-04-01  13
2  2011-07-01  18
3  2011-10-01  21
4  2012-01-01  43
5  2012-04-01  60
6  2012-07-01 122

Now let’s plug that into ggplot:

ggplot(data = meetupMembers %.% group_by(quarterYear) %.% summarise(n = n()) %.% mutate(n = cumsum(n)), 
       aes(x = quarterYear, y = n)) + 
    ylab("Number of members") +
    xlab("Date") +
2014 08 31 23 08 24
Categories: Blogs

Secret recipe for building self organizing teams

Agile World - Venkatesh Krishnamurthy - Sun, 08/31/2014 - 11:14

I authored this short post for image as part of Agile chronicles.

image Some time back I noticed something odd with an agile team. Team temperature used to be 10 out of 10, and each team member expressed their happiness working on this project.  I was curious to find the secret behind an “always happy team.” A bit of interaction with the team and the ScrumMaster revealed some disturbing secrets.  Here are the key ones:

  1. The team is self-organizing, and individuals can pick the story of their choice and deliver at their discretion!!
  2. Team has neither time pressure nor delivery timelines

I thought to myself that this is not a self-organizing team, but a directionless team.

As Esther Derby points out, there are several myths and misconceptions about Self-Organizing teams.  I did cover a bit about these myths during my talk at Lean Agile Systems Thinking conference(LAST) in Melbourne, which is available on Youtube (toward the end at 1:03 minutes).

I understand it is not easy to build a self-organizing team, but there are principles enabling leaders in building such agile teams.

One of the best analogies that I have heard so far about self-organizing teams is from Joseph Pelrine.  As Joseph puts it, building self-organizing teams is like preparing soup.  I thought it would be easier for readers to understand the self-organizing concept if I map the soup preparation steps to the self-organizing steps. Yes, soup preparation involves many more steps, but the key ones below would give the clues to readers for further analysis.

Read rest of the article on  : Agile Chronicles

Photo courtesy :

Categories: Blogs

Sneak Peak at Modern Management Framework


In China, "Kanban" simply means "looking at the board." For a Chinese audience, Kanban is encapsulated in the cartoon on the cover of my Kanban: Successful Evolutionary Change for your Technology Business. They don't need to look further than the characters standing in front of the board. Hence, to a Chinese mind, our management approach is centered around a standup meeting. All well and good and why not?

However, a senior executive at one of our clilents felt that this perception was likely to undermine the true value and the potential impact of our teachings on his business. So he suggested that we give the wider collection of ideas, intellectual property and teaching tools, a different name. It so happens I'd been thinking along similar lines and introducing terms and branding in our business to lay the foundation for this. So here it is, "The Modern Management Framework." This isn't new. It's the collection of our existing class curriculum and consulting tools but presented altogether in one place for the first time and under one banner.

read more

Categories: Companies

What jobs are you hiring Agile for?

Johanna Rothman wrote an article in her Pragmatic Manager newsletter called "Is Your Agile Journey Based on Problems or Process?" about starting an Agile transition, not by first selecting a "process", but by first considering values and using those values to solve problems.
Some people want to plan an entire agile transition from one team, to an entire organisation, as if they could imagine how the organization could change, all up front. Big Design Up Front, anyone?Let me suggest an alternative. Instead of selecting a process first, consider the agile values first. Are there values that resonate with you more? Maybe you build on those values first, solving your problems, using them as the basis for your agile transition. As you proceed, maybe you can integrate other values to build on your success. Based on the contents of the article, Johanna seems to actually be advocating starting with values rather than starting with problems, per se.

So what if we didn't start with values and started with problems?

How might that look?

At LAST conference 2014, I presented a session on the Agile Fluency Model and asked the question:
What jobs are we hiring Agile for?
Are you sure you're any good at this? Assessing Agile proficiency with the Agile Fluency Model from Jason Yip
Job 1: Create transparency and alignment to improve trustThe problem is stakeholders of delivery teams saying things like "We don't know what you're doing" and "Why are you doing that?".  Which means those stakeholders are much less likely to trust in what those teams are doing.
Job 2: Deliver reliably and more frequently to improve trust in capabilityThe problem is stakeholders looking at the delivery teams and organisation and saying "This is too slow, too expensive, with poor quality".  Which means that even if they are clear about what the teams are doing, those stakeholders don't consider them competent.
Job 3: Build better products and servicesThe problem is that stakeholders don't consider the delivery teams and organisation capable of being involved in product strategy.  "This is a product strategy session, we don't need your input."  Even if the stakeholders consider the teams competent, it does not include anything in terms of the direction of the product.
Job 4: Build an organisation that systemically builds better products and servicesThe problem is that stakeholders don't consider the delivery organisation capable of being involved in organisational business strategy.  "This is a business strategy session, we don't need your input."  Even if the stakeholders consider the teams competent in terms of both product strategy and delivery, this does not include the ability to trade-off multiple conflicting objectives at the overall organisation level.
Categories: Blogs

Pogo Connect vs Pencil

Derick Bailey - new ThoughtStream - Sat, 08/30/2014 - 15:53

If you’ve been paying attention to my blog and/or my weekly email in the last month or two, you’ve probably noticed all the hand-drawn illustrations. I can’t say I had really planned on doing this, at first, but once I started I couldn’t stop. I love drawing these little stick figures and scenes to visualize some aspect of what I’m writing. I enjoy the creative process of drawing, and the simplicity of the results (as well as the crudely drawn, yet expressive style that I have been developing). More importantly, I think it ads a unique and personal touch to the things i’m writing. Instead of some stock art or random photograph found from around the internet somewhere, I’m offering a little bit more of me – another aspect of the way I think and create, in the process of writing and illustrating the posts.

To make the drawings, I’m using the Paper app for iPad. Once I’m done, I transfer them to my computer (via iCloud photo sync) and do some light editing (image size, file size, creating the brightly white skin color on the stick figure heads) via the Acorn app on my Mac. But the Mac touch up side of things is the least important in the process, in my opinion. What really makes these images fun for me to draw and gives them a lot of the style that I enjoy so much, is the combination of the Paper app for iPad and the stylus that I am using to do the drawings. 

Fancy Stylus vs Fancy Stylus

I started with a Pogo Connect about a year ago. It’s been an amazing stylus. Recently, though, I picked up a Pencil by 53 – the same company that makes the Paper app. I wanted to see what the real difference between these two stylus is, to see if the Pencil really is as great as everyone says it is. Or were people only saying such great things in comparison to a cheap stylus that did not offer any real features?

Pogoconnect vs 53pencil

The Pogo Connect

I picked this up almost a year ago, and immediately started experimenting with it. I had previously been using a plain stylus, which was better than my finger but didn’t offer much in terms of usefulness other than not being my finger. The Pogo Connect, on the other hand, made drawing on my iPad significantly easier. I was found that I had more control, more precision and an easier time dealing with the drawing tools in the Paper app. This was true, even when I had the bluetooth connectivity of the Pogo Connect turned off. 

The design of the Pogo Connect is fairly simple. It’s round, sleek and has a very standard cylindrical shape with a cone for a tip. It’s light weight and comfortable to hold, being slightly larger than most cheap stylus that you would find. I do find that the button on the Connect gets in the way of comfort now and then, but that is easily remedied by turning the Connect in my hand. I tend to turn pencils and pens in my hand anyways, so this was never really a big issue; just something I notice now and then.

The real advantage that I found in the Connect, though, came from it’s advanced features, facilitated by a low energy bluetooth connection. With the Connect app installed and integration in to the Paper app, I suddenly had pressure sensitivity in my stylus. I was able to draw much more naturally using the tools in Paper, because of the integration that the app has with the Connect. Thin lines became easy, lightly colored areas were as natural as using a real pencil on real paper. I started drawing more, finding that the Pogo Connect allowed me more freedom in expression.

The button on the Connect serves multiple purposes. It allows you to connect the stylus to your iPad but it also provides features in apps that support the Connect. In the case of the Paper app, you can use the button as an undo command. Normally, you have to swipe two fingers counter-clockwise in Paper, to undo things. With the button on the Connect, though, undo is just a click away.

I have 2 over-all frustrations with the Connect: It can be tricky to get it connected to the iPad, and the button gets accidentally clicked a lot. The connection issue is usually resolved by turning bluetooth off / on, on the iPad. The button issue is resolved by turning off the “undo” feature of the button, in the Paper app. It’s mildly frustrating that I need to turn this off in order to keep from accidentally undoing work, though. I wish it were easier to avoid accidental clicks of the button.

Over-all, I really like the Connect. The pressure sensitivity is a great feature, it’s comfortable and I found myself wanting to draw when I had it, more than before I had it.

The Pencil, by 53

I’ve only had the Pencil for a little more than a month at this point, but I’ve been using it pretty regularly. Like the Pogo Connect, I immediately found that it was easier to use the Pencil than using my finger or a cheap style. It made drawing easier than using a standard stylus. I initially had some trouble getting the lines to go where I wanted them, due to the elongated touch area of the Pencil. I quickly got over this, though, and found myself as adept at using the Pencil as I was at using the Connect.

The design of the Pencil reminds me of a carpenter’s pencil, which I am very familiar with from my childhood and teenager days, thanks to my dad. It was a comfortable and familiar grip with quite a bit more weight.

I opted for the black, aluminum Pencil instead of the brown, real wood Pencil for a couple of reasons:

  1. it was $20 cheaper than the wood version, and
  2. I don’t need a magnet to stick it to my iPad

In addition to the tip that you draw with, the Pencil also has a rubberized touch area on the back of it. You can use this as an eraser, replacing the actual eraser tool in the Paper app, when the Pencil is connected via bluetooth.

Like the Pogo Connect, the Pencil has bluetooth connectivity. In the case of the Pencil, though, there is no button on the stylus to make the connection happen. You hold down a button in the Paper app and it makes the connection for you. Once connected, though, you have a couple of distinct advantages in using the Pencil: the eraser I previously mentioned, and a “blur” feature.

With the Pencil connected via bluetooth, you can hold the stylus up off of the iPad slightly and use your finger to create a blur in the Paper app. This is a unique feature in the app, available when the Pencil is connected. I really like this feature and have used it a number of times to create a smooth transition and background effect. In the above image, in fact, i used the blur feature of the Pencil to get the “shiny” highlight on the Pogo Connect drawing. You do need to be a bit careful with this, though. If you are not pressing the Pencil down on the iPad enough, you can accidentally blur instead of drawing a mark like you expected.

I have 1 major complaint and one minor frustration with the Pencil at this point. It does not support pressure sensitivity like the Connect, and it can be slightly less comfortable to hold some times.

The lack of pressure sensitivity was initially surprising and very frustrating. I had become used to this in the Pogo Connect and was sad that it was not available in the Pencil. Supposedly the elongated touch area of the Pencil is going to allow the same effect once iOS 8 is released, though. So we’ll have to wait and see about that.

The comfort of the Pencil is less of an issue than I originally thought. Having used it for over a month now, I find that I am no longer noticing the design of the Pencil when holding it. I have become accustomed to it, and find it comfortable at this point. 

Some Notes On The Above Drawing

The drawing at the top of this post was done with both the Pogo Connect and the Pencil. In fact, I draw the other stylus with the one I had in had. The Pogo Connect drawing was made with my Pencil, and the Pencil drawing was made with the Connect. But you want to know what really makes that odd? I don’t think the results of either drawing would have been correct, if I had not done it this way.

When drawing the Connect, I used the Pencil’s blur feature to get the “shiny” aluminum to look right. Without the blur feature, it was looking ok but it did not really look like an aluminum tube, the way the Connect really looks. 

When drawing the Pencil on the other hand, I would have not have been able to get the brushed aluminum style to look right without the pressure sensitivity of the Connect. I needed the ability to vary the intensity of the sketch marks, and create thin vs thick lines, to get the Pencil to look correct. 

It’s an odd thing when I need the features of one stylus to draw the other.

The Verdict: Pogo Connect or Pencil?

At roughly the same price on, both the Pogo Connect and Pencil are tools that I would highly recommend for anyone that is even halfway engaged in drawing with the Paper app, on an iPad. If you want pressure sensitivity right now, go with the Connect (vs waiting for iOS 8). If you want the blur feature and quick connectivity, go with the Pencil. Either way, you won’t be disappointed. Both of these tools are top notch, high quality and a pleasure to work with. 

That being said, I find myself grabbing my Pencil more often than my Pogo Connect. I believe there are 3 reasons for this:

  1. There is no accidental button click (though there are accidental blurs)
  2. The added blur effect in the Paper app
  3. The ease of which the Pencil connects to the Paper app

It’s that third reason that really draws me back to the Pencil right away. I find it significantly easier to get the Pencil connected to the Paper app, using the in-app icon that I hold down. Whereas the Connect requires me to exit the current drawing, go in to the settings for the Paper app and fiddle with things at times. It’s just easier to get the Pencil connected, and start using it’s features. 

Whatever your final decision is, though, both of these stylus have a lot to offer anyone that wants to get more out of their iPad and it’s many available drawing and painting applications.



     Related Stories 
Categories: Blogs

Do You Polish And Shine What You Have, Or Build More?

Derick Bailey - new ThoughtStream - Sat, 08/30/2014 - 05:02

“I have so many things I want to do. But I’m constantly torn: should I polish the things I have in place, already? Or should I build new features that will be more attractive?” – me (basically), talking to my friend and coworker, Justin Gregory, at lunch.

Build or polish

It’s a constant struggle with me. I see the big, rusty patch in my software. I know it could / should be done better. But then, SQUIRREL! and off I go to build something else. Cause who doesn’t like new things, right?

“Why Do You Like Them So Much?”

I’m rattling off the various things that a service I use doesn’t have and Justin wants to know why I still use them.

It’s obvious to me. What they do have is so dang easy to use, I couldn’t imagine using any of the competitors. I tell him how easy it is to use the service; to get the results I need; to make the API calls. I don’t even have to think about the data structure. I just shove data in and the information I need comes back out. 

It’s obvious. What they have is so dang polished, simple and enjoyable to use. Yes, I want those other things but I’m willing to wait for them, at this point. 

So, What Should You Do?

Do you build something new, exciting and going to be awesome? Or do you polish what you have, making it the best it can be?

Justin asks me one more question as we’re about to head back to the office, from lunch:

When was the last time you talked about how much you loved a service that did everything, but did it poorly?

     Related Stories 
Categories: Blogs

Calling all Agilistas! Another Year of Agile Ottawa is Ready to Go!

Agile Ottawa - Sat, 08/30/2014 - 02:07
The volunteer organizers of Agile Ottawa have been busy bees over the summer as we prepare for another year of Agile Ottawa meetup events.  In addition, our group is taking on a greater leadership role in organizing the Gatineau Ottawa Agile … Continue reading →
Categories: Communities

ScrumMaster Tales – Stuck Waiting for Other Teams

Notes from a Tool User - Mark Levison - Fri, 08/29/2014 - 22:53

Stop sign imageJohn (ScrumMaster) and the team are humming along nicely building great new features for the SmallestOnlineBookStore. With the huge success of the first big release nine months ago, venture capital money has come flowing into the company. Significant investments have been made in Operations, Security, and Networking in addition to creating several new Development Teams. Unfortunately, all these new people are making it more difficult for the team to get the software they built deployed.

The new groups are often imposing their own reviews and processes on the software before it’s deployed. Some changes are going to increase the load on the network and require review by the network team. Other changes affect the payment gateway, backend administration, and the services team who have a lead time of three weeks. All of these reviews, while increasing safety, have greatly slowed the delivery of new features.

The Development Team is getting frustrated because they feel their work is slowed artificially by the teams downstream of them (i.e. Networking and Security). The customers are getting annoyed because the previously great flow of features has slowed down to a crawl.

In addition, the team has created a Work in Progress (aka WIP) of one story per developer. This is both exacerbating and revealing the problem. It’s exacerbating because the team doesn’t have background to work on whenever their main task is stuck. It also reveals that the real problem isn’t at the team level where the work is getting to “almost” done.

John creates a short list of options for the team: Increase individual WIP limits to 2; Change the Definition of Done so that Security and Network reviews aren’t part of Done; Add a column to their Scrum Task Wall to account for both other groups and start working with the other departments to clear work more quickly.


Before we explore options in a situation like this I prefer to gather data. The best way in this case would be to create a Kanban wall that tracks the progress of a Story from initial idea to the moment it’s deployed and is delighting customers. This, combined with a Cumulative Flow Diagram, will help the source of the Team’s stress.

John, being aware this might be an issue, has been tracking the data for just over a month:


From the data we can produce a Cumulative Flow Diagram that looks like this:

Cumulative Flow Diagram

So what does this chart show? The team isn’t the bottleneck in this case. A simple test I use to tell is this:

“If we had a magical way to double the rate at which you deliver stories/features, would that make any real change in the rate at which customers get the features?”

At the development team level – Code, Code Review, Testing – clearly that isn’t the case, the bottleneck is in “Done in Development”, which is really just a buffer, and Network/Security review. Rather than make changes at the team level, we need to see what we can do to optimize the downstream work.

Based on this data, let’s re-examine the team’s options:

  • Increase Individual WIP Limit from 1 to 2 – This really just masks the problem giving something else for someone to work on when their original item is stuck in Network or Security. As we’ve already seen the limit isn’t at the team level, so optimizing there won’t help.
  • Change the Definition of Done so that a Story is considered Done when it’s handed off to an outside team. – This doesn’t really help the customer since the item still isn’t deployed, it just makes each individual developer feel better. However, in creating an additional column for the downstream groups, we have effectively created a Definition of Done for each column. Kanban calls these “policies”. So we have changed “Done” but only in the name of making our problems more apparent.
  • Add a column to the Scrum Task WallWe didn’t quite do that, instead we created a Kanban wall that acknowledges some of the work is beyond our team’s span of control.


So let’s add a new option:

  • Start working with the other departments to clear work more quicklyIn a Kanban oriented world, teams swarm downstream blockages. This would definitely be a good idea in our case.


Were I coaching John, I would get him to setup the Kanban tracking wall with the other teams and departments so that the entire company gets a view of where the work stands. I would invite people from each group to come update the wall every couple of days. By getting their involvement in set up and tracking, people from the other teams (i.e. Security and Networking) will appreciate that the data reflects their world and they will be more open to acting on the data. In addition, John (and his team) will gain greater insight into what is affecting Networks and Security – perhaps the company was suffering from a Denial of Service attack at the end of June and for a few days both teams were pulled from reviewing to handle the operational problem.

The team might also discover that they’re found to frequently be violating security practices. In this case, mentoring from Security might increase the team’s level of skill in this area, and reduce time spent in the review phase. Very often in cases like this, cross-training the team (see: The Team Gets Bottlenecked) to help reduce the downstream bottleneck will help, however we won’t know until we’ve gathered data and worked with the other teams to find out what the real problem is.

As an aside, I don’t recommend individual WIP limits when working as part of a Scrum Team – instead focus on the WIP for the entire team. It’s a small change, but it makes it clear that the productivity of the team is more important than that of any one individual.

Categories: Blogs

Fostering the Culture of Agility with Servant Leadership

Illustrated Agile - Len Lagestee - Fri, 08/29/2014 - 18:12

The phrase “servant leadership” is frequently used when current leadership styles (typically command-and-control) clash with an emerging culture of empowerment and self-organization. “We need our leaders to embody servant leadership” is a comment I recently heard. But what is servant leadership? Do people really know what they are asking for?

As Patrick Lencioni states “I’m tired of hearing about servant leadership…because there is not any other kind.” I would agree. For leaders looking to radically thrive in an environment of agility and to foster the culture necessary for an Agile ecosystem to work, looking to Robert Greenleaf’s seminal book establishes a life-long foundation to build your leadership legacy.

One interesting concept from Mr. Greenleaf is the notion of primus inter pares or, first among equals. This approach no longer places the leader at the top of a hierarchy but along side their peers. So, who is the leader? The one with foresight – the one with the ability to see things others can’t see – and the one who has the ability to build community. Leaders are no long chosen for their followers. Followers choose the leader. I often wonder how many people would continue to follow their current manager if they were given the choice. Something to think about…

This is just one of many principles and characteristics of a servant leader described in the book. I recently elaborated 7 of these principles to include in training materials to use while teaching and coaching servant leadership. You can download the PDF of these materials here.

Becoming a “servant leader” is a lifelong journey and this document is just the tip of the iceberg and a conversation starter. Feel free to share freely and contribute your thoughts on servant leadership below.

Download Servant Leadership Principles from Illustrated Agile.

Servant Leadership by Robert Greenleaf
10 Principles of Servant Leadership

Becoming a Catalyst - Scrum Master Edition

The post Fostering the Culture of Agility with Servant Leadership appeared first on Illustrated Agile.

Categories: Blogs

R: dplyr – group_by dynamic or programmatic field / variable (Error: index out of bounds)

Mark Needham - Fri, 08/29/2014 - 11:13

In my last blog post I showed how to group timestamp based data by week, month and quarter and by the end we had the following code samples using dplyr and zoo:

timestampToDate <- function(x) as.POSIXct(x / 1000, origin="1970-01-01", tz = "GMT")
query = "MATCH (:Person)-[:HAS_MEETUP_PROFILE]->()-[:HAS_MEMBERSHIP]->(membership)-[:OF_GROUP]->(g:Group {name: \"Neo4j - London User Group\"})
         RETURN membership.joined AS joinTimestamp"
meetupMembers = cypher(graph, query)
meetupMembers$joinDate <- timestampToDate(meetupMembers$joinTimestamp)
meetupMembers$monthYear <- as.Date(as.yearmon(meetupMembers$joinDate))
meetupMembers$quarterYear <- as.Date(as.yearqtr(meetupMembers$joinDate))
meetupMembers %.% group_by(week) %.% summarise(n = n())
meetupMembers %.% group_by(monthYear) %.% summarise(n = n())
meetupMembers %.% group_by(quarterYear) %.% summarise(n = n())

As you can see there’s quite a bit of duplication going on – the only thing that changes in the last 3 lines is the name of the field that we want to group by.

I wanted to pull this code out into a function and my first attempt was this:

groupMembersBy = function(field) {
  meetupMembers %.% group_by(field) %.% summarise(n = n())

And now if we try to group by week:

> groupMembersBy("week")
 Show Traceback
 Rerun with Debug
 Error: index out of bounds

It turns out if we want to do this then we actually want the regroup function rather than group_by:

groupMembersBy = function(field) {
  meetupMembers %.% regroup(list(field)) %.% summarise(n = n())

And now if we group by week:

> head(groupMembersBy("week"), 20)
Source: local data frame [20 x 2]
         week n
1  2011-06-02 8
2  2011-06-09 4
3  2011-06-16 1
4  2011-06-30 2
5  2011-07-14 1
6  2011-07-21 1
7  2011-08-18 1
8  2011-10-13 1
9  2011-11-24 2
10 2012-01-05 1
11 2012-01-12 3
12 2012-02-09 1
13 2012-02-16 2
14 2012-02-23 4
15 2012-03-01 2
16 2012-03-08 3
17 2012-03-15 5
18 2012-03-29 1
19 2012-04-05 2
20 2012-04-19 1

Much better!

Categories: Blogs

Inspirational Work Quotes at a Glance

J.D. Meier's Blog - Fri, 08/29/2014 - 09:00

What if your work could be your ultimate platform? … your ultimate channel for your growth and greatness?

We spend a lot of time at work. 

For some people, work is their ultimate form of self-expression

For others, work is a curse.

Nobody stops you from using work as a chance to challenge yourself, to grow your skills, and become all that you’re capable of.

But that’s a very different mindset than work is a place you have to go to, or stuff you have to do.

When you change your mind, you change your approach.  And when you change your approach, you change your results.   But rather than just try to change your mind, the ideal scenario is to expand your mind, and become more resourceful.

You can do so with quotes.

Grow Your “Work Intelligence” with Inspirational Work Quotes

In fact, you can actually build your “work intelligence.”

Here are a few ways to think about “intelligence”:

  1. the ability to learn or understand things or to deal with new or difficult situations (Merriam Webster)
  2. the more distinctions you have for a given concept, the more intelligence you have

In Rich Dad, Poor Dad, Robert Kiyosaki, says, “intelligence is the ability to make finer distinctions.”   And, Tony Robbins, says “intelligence is the measure of the number and the quality of the distinctions you have in a given situation.”

If you want to grow your “work intelligence”, one of the best ways is to familiarize yourself with the best inspirational quotes about work.

By drawing from wisdom of the ages and modern sages, you can operate at a higher level and turn work from a chore, into a platform of lifelong learning, and a dojo for personal growth, and a chance to master your craft.

You can use inspirational quotes about work to fill your head with ideas, distinctions, and key concepts that help you unleash what you’re capable of.

To give you a giant head start and to help you build a personal library of profound knowledge, here are two work quotes collections you can draw from:

37 Inspirational Quotes for Work as Self-Expression

Inspirational Work Quotes

10 Distinct Ideas for Thinking About Your Work

Let’s practice.   This will only take a minute, and if you happen to hear the right words, which are the keys for you, your insight or “ah-ha” can be just the breakthrough that you needed to get more of your work, and, as a result, more out of life (or at least your moments.)

Here is a sample of distinct ideas and depth that you use to change how you perceive your work, and/or how you do your work:

  1. “Either write something worth reading or do something worth writing.” — Benjamin Franklin
  2. “You don’t get paid for the hour. You get paid for the value you bring to the hour.” — Jim Rohn
  3. “Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do.” — Steve Jobs
  4. “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” -- Bill Gates
  5. “We must each have the courage to transform as individuals. We must ask ourselves, what idea can I bring to life? What insight can I illuminate? What individual life could I change? What customer can I delight? What new skill could I learn? What team could I help build? What orthodoxy should I question?” – Satya Nadella
  6. “My work is a game, a very serious game.” — M. C. Escher
  7. “Hard work is a prison sentence only if it does not have meaning. Once it does, it becomes the kind of thing that makes you grab your wife around the waist and dance a jig.” — Malcolm Gladwell
  8. “The test of the artist does not lie in the will with which he goes to work, but in the excellence of the work he produces.” -- Thomas Aquinas
  9. “Are you bored with life? Then throw yourself into some work you believe in with all you heart, live for it, die for it, and you will find happiness that you had thought could never be yours.” — Dale Carnegie
  10. “I like work; it fascinates me. I can sit and look at it for hours.” -– Jerome K. Jerome

For more ideas, take a stroll through my inspirational work quotes.

As you can see, there are lots of ways to think about work and what it means.  At the end of the day, what matters is how you think about it, and what you make of it.  It’s either an investment, or it’s an incredible waste of time.  You can make it mundane, or you can make it matter.

The Pleasant Life, The Good Life, and The Meaningful Life

Here’s another surprise about work.   You can use work to live the good life.   According to Martin Seligman, a master in the art and science of positive psychology, there are three paths to happiness:

  1. The Pleasant Life
  2. The Good Life
  3. The Meaningful Life

In The Pleasant Life, you simply try to have as much pleasure as possible.  In The Good Life, you spend more time in your values.  In The Meaningful Life, you use your strengths in the service of something that is bigger than you are.

There are so many ways you can live your values at work and connect your work with what makes you come alive.

There are so many ways to turn what you do into service for others and become a part of something that’s bigger than you.

If you haven’t figured out how yet, then dig deeper, find a mentor, and figure it out.

You spend way too much time at work to let your influence and impact fade to black.

You Might Also Like

40 Hour Work Week at Microsoft

Agile Avoids Work About Work

How Employees Lost Empathy for Their Work, for the Customer, and for the Final Product

Satya Nadella on Live and Work a Meaningful Life

Short-Burst Work

Categories: Blogs

Visualisierung in Projekten: Braucht Skalierung Tools?

Scrum 4 You - Fri, 08/29/2014 - 07:54

“Big Visible Charts” war einmal das Motto – Scrum-Teams wollten schnell ihre Informationen an jene mitteilen, die daran vorbeigehen. Ein wundervolles Beispiel für diese Variante der Informationsverbreitung findet sich hier. Die Idee war es, physisch und haptisch, schnell und ohne viel Aufwand Teams zu ermöglichen, effektiver zu arbeiten.

Dann kamen die Leute, die unbedingt die große, allumfassende Visualisierung über alle Projekte haben wollten. Sie setzen immer noch Entwickeln mit Produktion gleich und wollten per Mouse Click haben, was bis dato kein MS Projekt Ghantt-Chart konnte: Tagesaktuelle, verlässliche und korrekte Zahlen über den Entwicklungsfortschritt liefern. Sprich: Reporting bis zum Exzess.

Findige und geniale Entwickler wie zum Beispiel die Jungs von Atlassian bauten coole Tools wie Jira, Greenhopper, und einige andere entwarfen die wirklich abgefahrenen Lösungen wie Trello, VerisonOne, Mingle und wie sie alle heißen, damit sie die geforderten Informationen möglichst schnell und einfach liefern konnten.
Und was passiert jetzt: Es gibt Software-Entwickler, die ihr Geld damit verdienen, z.B. JIRA für Kunden zu konfigurieren, die Workflows anzupassen, und aus der simplen Idee von drei Spalten – TODO, INPRG, DONE – wochenlange Entwicklungsprojekte zu machen. Das ist zwar eine tolle Einnahmequelle und wir als Scrum Consulting Firma werden vielleicht sogar schwach und machen das bald auch – aber das war nicht der Sinn und die Idee hinter alldem. Was wir wollten, war ganz einfach: Wissensarbeit sichtbar machen, damit man darüber sprechen kann. Mehr nicht. Damit ein Teammitglied dem anderen helfen kann. Damit klar wird, wo es noch Lücken gibt und wo man sofort eingreifen kann.

Die Entwicklung geht aber leider in die – meines Erachtens – falsche Richtung. Scrum Entwicklungsteams werden automatisiert dazu gezwungen, über jede Story und jede Zeile Code Rechenschaft abzulegen. Ihre  Chefs, leider oft auch die Product Owner, müssen das nicht. Warum eigentlich? Wieso wird von den Entwicklern diese Transparenz erwartet, nicht aber von denjenigen, die die Ansagen machen?
Meine klare Vermutung: Es würde zu deutlich zeigen, dass dort gar nichts produziert wird. Dort wird keine Leistung, keine Wertschöpfung erbracht. Erklären Sie doch einmal der nächsthöheren Ebene, was Sie den ganzen Tag in den 6 Meetings zu je 90 Minuten und in den 10 Telefonaten dazwischen produziert haben.

Wir haben in unserem Unternehmen die Beweiskette, den Nachweis, dass etwas passiert, umgekehrt. Ich muss klar darlegen, was ich tue. Ich führe ein Backlog, das sich alle in einem Confluence Wiki ansehen können. Dort stehen alle Aktivitäten (fast alle – ich vergesse auch mal was), die ich an einem Tag ausführe, und ich lege die Ziele ebenfalls öffentlich ab. Nicht weil ich sie vorgeben will, sondern weil wir sie nur dann diskutieren können, wenn wir sie immer wieder sehen. Man kann nur über etwas reden, das man offenlegt.

Und wisst ihr, was passiert ist? Es hat Schule gemacht. Jeder legt nun das, was er tut, ganz von selbst offen. Wir haben noch kein Taskboard – noch nutzen wir ein Wiki. Vielleicht nutzen wir auch bald mal JIRA intern ;-)  - als verteiltes, skaliertes und multikultures Team. Aber nicht, damit mir meine Kollegen reporten, sondern damit sichtbar wird, wer gerade woran arbeitet und sich die Kollegen gegenseitig helfen können – egal, wo sie gerade sitzen. Internationalisierung, das remote Arbeiten und das ständige mobil Onlinesein lässt sich nicht mehr zurückdrehen. Wer diese Geschwindigkeitsvorteile nutzen will, darf Tools für die  Zusammenarbeit über die Grenzen eines Büros hinaus nicht mit Reportingtools für das Management verwechseln oder sie dafür missbrauchen.

Related posts:

  1. DeutscheScrum
  2. Eindrücke eines Teilnehmers an CSM Training mit ScrumCooking
  3. Scrum Tools | Protonotes | Review

Categories: Blogs

The Agile Reader – Weekend Edition: 08/29/2014 - Kane Mar - Fri, 08/29/2014 - 04:22

You can get the Weekend Edition delivered directly to you via email by signing up

The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.

  • RT @ScrumDan: Embrace Change + Learn from Mistakes = Successful Agile Implementation #agile #scrum
  • Are you implementing Scrum but realize you are better suited for Kanban? #Agile #Scrum #Kanban
  • RT @braintrustgroup: Benefits of #Scrum – Management Perspective: Enhanced Stakeholder relationships #project #agile…
  • RT @DM_Lorenzo: 9 Tips to manage your #SoftwareDevelopment projects #agile #scrum please RT
  • Benefits of #Scrum – Team Perspective: A safe working environment where people can thrive. #software #project #agile
  • RT @braintrustgroup: Benefits of #Scrum – Team Perspective: A safe working environment where people can thrive. #sof…
  • RT @yochum: Agile Denver Session Notes: Unscaling #agile #scrum
  • Retrospectives Pre-Requirements – #retrospectives #scrum #agile
  • Cynefin and Story Splitting #agile #scrum
  • A #scrum master who relies on command & control is an impediment, not a servant leader. #agile
  • Are you struggling with backlog refining meetings that aren’t productive? #Scrum #agile #BacklogRefining #Estimating
  • RT @ryanripley: A #scrum master who relies on command & control is an impediment, not a servant leader. #agile http:…
  • [vidéo] Legos, méthode agile Scrum 3D et imagination : The LEGO House By B.I.G via @_theinspiration
  • Planning, Tracking and Managing Agile Web Development Sprints using Scrum and Intervals ~
  • - Short weekly blog based around Scrum and Agile…
  • RT @MichaelNir: #RT #AUTHORRT #scrum that works ** ** #agile #project #productowner
  • The Board – Episode 34 – Scrum vs. Kanban #Scrum #Agile
  • The Board – Episode 34 – Scrum vs. Kanban #Scrum #Agile
  • Avenue Code is offering a 2-day Certified Scrum Master Training. Here is more info! #scrum #agile #training
  • Do you want to complete projects efficiently? Check out the FREE SCRUM EBOOK: #scrum #agile inspired by #kschwaber
  • #RT #AUTHORRT #scrum that works ** ** #agile #project #productowner
  • Ken Schwaber talks to InfoWorld about the origins of #Scrum: #agile
  • RT @JamesMDonovan: DevOps #IBMRational web session: — Agile/SCRUM features coming in v5.0.1 of Team Concert, presen…
  • The Board – Episode 35 – Agile Fluency #Scrum #Agile
  • The Board – Episode 35 – Agile Fluency #Scrum #Agile
  • How does #availabilitybias affect #projectmanagement? via @RichEarthPM #scrum #agile #pm #project
  • Two week sprints is the standard, but a different length might be better for your team or project #scrum #agile
  • Site catalyst Analyst – Adobe Analytics Agile SCRUM – (Seattle) #Seattle #WA #News
  • #Agile #Scrum Sprint Length: Whats Right for You? My 2c: The key consideration is the PO’s ability to release value.
  • RT @dr_ian_mitchell: #Agile #Scrum Sprint Length: Whats Right for You? My 2c: The key consideration is the PO’s abil…
  • Agile Software Development with Scrum and press release #agile
  • RT @sdtimes: Experts explain how to transition to agile, best practices and what to watch out for #agile #scrum #kan…
  • RT @MichaelNir: #RT #AUTHORRT #scrum that works ** ** #agile #project #productowner
  • RT @IBMCSC: #IBMCSC Brazil 18 adopting Agile Scrum to help preserve the rainforest w/ @nature_org #HelpsCSCBrazil @M…
  • Site catalyst Analyst – Adobe Analytics Agile SCRUM – (Seattle) #Seattle #WA #News
  • Check out this Meetup TONIGHT with Portland Agile &amp; Scrum Meetup Group! 6:15 at ADP Plaza.
  • RT @PDXProductCamp: Check out this Meetup TONIGHT with Portland Agile &amp; Scrum Meetup Group! 6:15 at ADP Plaz…
  • #Strongsville, OH #IT #Job: Agile Scrum Master – Project Manager 14-266 at Medical Mutual #Jobs
  • RT @MichaelNir: #RT #AUTHORRT #scrum that works ** ** #agile #project #productowner
  • RT @braintrustgroup: Benefits of #Scrum – Team Perspective: A safe working environment where people can thrive. #sof…
  • The Board – Episode 36 – Designing Agile Spaces #Scrum #Agile
  • The Board – Episode 36 – Designing Agile Spaces #Scrum #Agile
  • RT @scrumology: The Board – Episode 36 – Designing Agile Spaces #Scrum #Agile
  • RT @scrumology: The Board – Episode 34 – Scrum vs. Kanban #Scrum #Agile
  • Site catalyst Analyst – Agile SCRUM Adobe Analytics – (Seattle) #Seattle #WA #News
  • Next Agile Ottawa Meetup Tues Sept 9! @pg5150 talking about User Story Mapping – don’t miss it
  • RT @eegrove: Next Agile Ottawa Meetup Tues Sept 9! @pg5150 talking about User Story Mapping – don’t miss it
  • RT @DeloitteDIGI_US: Scrumban: A different way to be Agile – @paulgambill #scrum #scrumban
  • Site catalyst Analyst – Adobe Analytics Agile SCRUM – (Seattle) #Seattle #WA #News
  • Can you explain the Benefits of #Scrum from multiple perspectives? Here’s a summary that is helpful – #product #agile
  • RT @eegrove: Next Agile Ottawa Meetup Tues Sept 9! @pg5150 talking about User Story Mapping – don’t miss it
  • RT @eegrove: Next Agile Ottawa Meetup Tues Sept 9! @pg5150 talking about User Story Mapping – don’t miss it
  • The Board – Episode 35 – Agile Fluency #agile #scrum
  • The Board – Episode 36 – Designing Agile Spaces #agile #scrum
  • RT @yochum: The Board – Episode 36 – Designing Agile Spaces #agile #scrum
  • RT @yochum: The Board – Episode 36 – Designing Agile Spaces #agile #scrum
  • Low-code development platforms #scrum #agile
  • FREE SCRUM EBOOK #Scrum #Agile inspired by #Ken Schwaber
  • Agile Scrum isn’t a silver bullet solution for s/w development, but it can be a big help. #AppsTrans #HP
  • RT @ReleaseTEAMLTD: Agile Software Development with Scrum and press release…
  • Here’s a video explaining #agile #development team best practices w/ #scrum particle physics @SolutionsIQ
  • RT @MichaelNir: #RT #AUTHORRT #scrum that works ** ** #agile #project #productowner
  • Project Manager – Urgent – Prince 2, Agile, Scrum, Budget, CRM Job Crawley
  • I’m attending a Meetup with Portland Agile & Scrum Meetup Group
  • Agile by McKnight, Scrum by Day is out! Stories via @AntonyMarcano @EmmyHermina
  • RT @versionone: Here’s a video explaining #agile #development team best practices w/ #scrum particle physics @Soluti…
  • Transparency in your daily life is so damn important. Especially at your job. #Scrum
  • RT @IBMCSC: #IBMCSC Brazil 18 adopting Agile Scrum to help preserve the rainforest w/ @nature_org #HelpsCSCBrazil @M…
  • Categories: Blogs

    R: Grouping by week, month, quarter

    Mark Needham - Fri, 08/29/2014 - 02:25

    In my continued playing around with R and meetup data I wanted to have a look at when people joined the London Neo4j group based on week, month or quarter of the year to see when they were most likely to do so.

    I started with the following query to get back the join timestamps:

    query = "MATCH (:Person)-[:HAS_MEETUP_PROFILE]->()-[:HAS_MEMBERSHIP]->(membership)-[:OF_GROUP]->(g:Group {name: \"Neo4j - London User Group\"})
             RETURN membership.joined AS joinTimestamp"
    meetupMembers = cypher(graph, query)
    > head(meetupMembers)
    1 1.376572e+12
    2 1.379491e+12
    3 1.349454e+12
    4 1.383127e+12
    5 1.372239e+12
    6 1.330295e+12

    The first step was to get joinDate into a nicer format that we can use in R more easily:

    timestampToDate <- function(x) as.POSIXct(x / 1000, origin="1970-01-01", tz = "GMT")
    meetupMembers$joinDate <- timestampToDate(meetupMembers$joinTimestamp)
    > head(meetupMembers)
      joinTimestamp            joinDate
    1  1.376572e+12 2013-08-15 13:13:40
    2  1.379491e+12 2013-09-18 07:55:11
    3  1.349454e+12 2012-10-05 16:28:04
    4  1.383127e+12 2013-10-30 09:59:03
    5  1.372239e+12 2013-06-26 09:27:40
    6  1.330295e+12 2012-02-26 22:27:00

    Much better!

    I started off with grouping by month and quarter and came across the excellent zoo library which makes it really easy to transform dates:

    meetupMembers$monthYear <- as.Date(as.yearmon(meetupMembers$joinDate))
    meetupMembers$quarterYear <- as.Date(as.yearqtr(meetupMembers$joinDate))
    > head(meetupMembers)
      joinTimestamp            joinDate  monthYear quarterYear
    1  1.376572e+12 2013-08-15 13:13:40 2013-08-01  2013-07-01
    2  1.379491e+12 2013-09-18 07:55:11 2013-09-01  2013-07-01
    3  1.349454e+12 2012-10-05 16:28:04 2012-10-01  2012-10-01
    4  1.383127e+12 2013-10-30 09:59:03 2013-10-01  2013-10-01
    5  1.372239e+12 2013-06-26 09:27:40 2013-06-01  2013-04-01
    6  1.330295e+12 2012-02-26 22:27:00 2012-02-01  2012-01-01

    The next step was to create a new data frame which grouped the data by those fields. I’ve been learning dplyr as part of Udacity’s EDA course so I thought I’d try and use that:

    > head(meetupMembers %.% group_by(monthYear) %.% summarise(n = n()), 20)
        monthYear  n
    1  2011-06-01 13
    2  2011-07-01  4
    3  2011-08-01  1
    4  2011-10-01  1
    5  2011-11-01  2
    6  2012-01-01  4
    7  2012-02-01  7
    8  2012-03-01 11
    9  2012-04-01  3
    10 2012-05-01  9
    11 2012-06-01  5
    12 2012-07-01 16
    13 2012-08-01 32
    14 2012-09-01 14
    15 2012-10-01 28
    16 2012-11-01 31
    17 2012-12-01  7
    18 2013-01-01 52
    19 2013-02-01 49
    20 2013-03-01 22
    > head(meetupMembers %.% group_by(quarterYear) %.% summarise(n = n()), 20)
       quarterYear   n
    1   2011-04-01  13
    2   2011-07-01   5
    3   2011-10-01   3
    4   2012-01-01  22
    5   2012-04-01  17
    6   2012-07-01  62
    7   2012-10-01  66
    8   2013-01-01 123
    9   2013-04-01 139
    10  2013-07-01 117
    11  2013-10-01  94
    12  2014-01-01 266
    13  2014-04-01 359
    14  2014-07-01 216

    Grouping by week number is a bit trickier but we can do it with a bit of transformation on our initial timestamp:

    meetupMembers$week <- as.Date("1970-01-01")+7*trunc((meetupMembers$joinTimestamp / 1000)/(3600*24*7))
    > head(meetupMembers %.% group_by(week) %.% summarise(n = n()), 20)
             week n
    1  2011-06-02 8
    2  2011-06-09 4
    3  2011-06-16 1
    4  2011-06-30 2
    5  2011-07-14 1
    6  2011-07-21 1
    7  2011-08-18 1
    8  2011-10-13 1
    9  2011-11-24 2
    10 2012-01-05 1
    11 2012-01-12 3
    12 2012-02-09 1
    13 2012-02-16 2
    14 2012-02-23 4
    15 2012-03-01 2
    16 2012-03-08 3
    17 2012-03-15 5
    18 2012-03-29 1
    19 2012-04-05 2
    20 2012-04-19 1

    We can then plug that data frame into ggplot if we want to track membership sign up over time at different levels of granularity and create some bar charts of scatter plots depending on what we feel like!

    Categories: Blogs

    This is Way Better Than the Ice Bucket Challenge!

    Agile Management Blog - VersionOne - Thu, 08/28/2014 - 22:16

    If you feel like there’s a lot of time being idled away on the Ice Bucket Challenge and other wacky, brainless activities, we have a better idea to spend your time. In just 10 minutes you could do something really valuable for the agile software community.

    But first I’m hoping to get just a tiny smile out of you by sharing something I wrote on our Product Blog earlier this week — just in case you aren’t subscribed there. If you are, just ignore this and go straight to the punch line.

    I posed this question:

    What’s the Best Way to Spend 10 Minutes?

    Let’s think about this for a minute…

    You could:

    • Ice-bucket challenge someone
    • Set a stapler in a Jell-o moldStapler
    • Crash someone’s Facebook by inviting them to Candy Crush
    • Add a ‘Blue Screen of Death’ screen saver to your boss’s laptop
    • Load a DVORAK driver onto a PC with a normal keyboard
    • Clean those 24 sticky coffee rings off your desk
    • Assign a bunch of fake stories to people

    But if you really want to make a lasting and meaningful impact on the agile software community, please find 10 minutes to take the 2014 State of Agile survey.



    “The annual State of Agile survey has become one of the most comprehensive industry surveys serving the agile community. The survey gives agile software professionals an extensive set of relevant statistics, peer guidance and validation that can be very helpful in making smarter decisions about their delivery process.”

    - SD Times Editor-in-Chief David Rubinstein

    Now in its 9th year, the State of Agile has helps agile practitioners, consultants, technology students, professors, bloggers and business people in all industries better understand agile methods and practices. The survey runs late summer through mid-September and VersionOne publishes the report in Q4 or early Q1.

    If you take it, you get:

    • Entered into a drawing for 1 of 9 SONOS wireless HiFi systems (each worth 600 bucks)
    • Exclusive, early access to the data sample from 2,000-4,000 respondents in your industry
    • Satisfaction that you helped others make informed decisions about their agile practices – in just 10 minutes

    What are you waiting for? Take the State of Agile survey now.

    take survey now image


    Categories: Companies

    Lean Startup Metrics and Analytics to Support Innovation and Learning in the Enterprise

    BigVisible Solutions :: An Agile Company - Thu, 08/28/2014 - 22:04

    At BigVisible we’ve been helping companies improve the way they work; HOW they produce technology products for well over a decade. We’ve seen amazing improvements in organizations’ ability to release quickly, accelerate time to market, improve quality, and engage in faster feedback cycles for better products and less waste. As delivery becomes more agile and […]

    The post Lean Startup Metrics and Analytics to Support Innovation and Learning in the Enterprise appeared first on BigVisible Solutions.

    Categories: Companies

    Cynefin and Story Splitting

    Agile For All - Bob Hartman - Thu, 08/28/2014 - 19:42
    Cynefin as of June 2014 - From Dave Snowden, released under CC BY 3.0

    Cynefin as of June 2014 – From Dave Snowden, released under CC BY 3.0

    As I was preparing for my Agile Denver session on Unscaling, which leaned heavily on the Cynefin Framework, I reread Liz Keogh’s excellent post, “Cynefin for Devs.” I realized that I use my story splitting patterns in a few different ways depending on the domain, and I’ve never been explicit about this (which probably confuses people I’m coaching).

    Unless you’re already familiar with Cynefin, go read Liz’s post. I’ll wait.

    Here’s how story splitting looks different for each Cynefin domain:

    Simple/Obvious – Just build it. Or, if it’s too big, find all the stories, and do the most valuable ones first.
    Complicated – Find all the stories, and do the most valuable and/or most risky ones first.
    Complex – Don’t try to find all the stories. Find one or two that will provide some value and teach you something about the problem and solution, build those and use what you learn to find the rest.
    Chaotic – Put out the fire; splitting stories probably isn’t important right now.
    Disordered – Figure out which domain you’re in before splitting so you don’t take the wrong approach.

    The most important nuance is in the complex domain, where starting the work will teach you about the work. In this situation, it doesn’t make sense to try to find all the small stories that add up to the original, big one. Instead, it’s more productive to find one or two you can start right away in order to learn.

    Some are uncomfortable with this approach, wanting all the stories enumerated and sized to be able to project time over the backlog. But if you’re really in the complex domain, this only gives you the illusion of predictability—the actual stories are likely to change as you get into the work. Better to be transparent about the uncertainty inherent in complex work.

    The post Cynefin and Story Splitting appeared first on Agile For All.

    Categories: Blogs

    Managers Manage Ambiguity

    Johanna Rothman - Thu, 08/28/2014 - 17:47

    I was thinking about the Glen Alleman’s post, All Things Project Are Probabilistic. In it, he says,

    Management is Prediction

    as a inference from Deming. When I read this quote,

    If you can’t describe what you are doing as a process, you don’t know what you’re doing. –Deming

    I infer from Deming that managers must manage ambiguity.

    Here’s where Glen and I agree. Well, I think we agree. I hope I am not putting words into Glen’s mouth. I am sure he will correct me if I am.

    Managers make decisions based on uncertain data. Some of that data is predictive data.

    For example, I suggest that people provide, where necessary, order-of-magnitude estimates of projects and programs. Sometimes you need those estimates. Sometimes you don’t. (Yes, I have worked on programs where we didn’t need to estimate. We needed to execute and show progress.)

    Now, here’s where I suspect Glen and I disagree:

    1. Asking people for detailed estimates at the beginning of a project and expecting those estimates to be true for the entire project. First, the estimates are guesses. Second, software is about learning, If you work in an agile way, you want to incorporate learning and change into the project or program. I have some posts about estimation in this blog queue where I discuss this.
    2. Using estimation for the project portfolio. I see no point in using estimates instead of value for the project portfolio, especially if you use agile approaches to your projects. If we finish features, we can end the project at any time. We can release it. This makes software different than any other type of project. Why not exploit that difference? Value makes much more sense. You can incorporate cost of delay into value.
    3. If you use your estimate as a target, you have some predictable outcomes unless you get lucky: you will shortchange the feature by decreasing scope, incur technical debt, or increase the defects. Or all three.

    What works for projects is honest status reporting, which traffic lights don’t provide. Demos provide that. Transparency about obstacles provides that. The ability to be honest about how to solve problems and work through issues provides that.

    Much has changed since I last worked on a DOD project. I’m delighted to see that Glen writes that many government projects are taking more agile approaches. However, if we always work on innovative, new work, we cannot predict with perfect estimation what it will take at the beginning, or even through the project. We can better our estimates as we proceed.

    We can have a process for our work. Regardless of our approach, as long as we don’t do code-and-fix, we do. (In Manage It! Your Guide to Modern, Pragmatic Project Management, I say to choose an approach based on your context, and to choose any lifecycle except for code-and-fix.)

    We can refine our estimates, if management needs them. The question is this: why does management need them? For predicting future cost for a customer? Okay, that’s reasonable. Maybe on large programs, you do an estimate every quarter for the next quarter, based on what you completed, as in released, and what’s on the roadmap. You already know what you have done. You know what your challenges were. You can do better estimates. I would even do an EQF for the entire project/program. Nobody has an open spigot of money.

    But, in my experience, the agile project or program will end before you expect it to. (See the comments on Capacity Planning and the Project Portfolio.) But, the project will only end early if you evaluate features based on value and if you collaborate with your customer. The customer will say, “I have enough now. I don’t need more.” It might occur before the last expected quarter. It might occur before the last expected half-year.

    That’s the real ambiguity that managers need to manage. Our estimates will not be correct. Technical leaders, project managers and product owners need to manage risks and value so the project stays on track. Managers need to ask the question: What if the project or program ends early?

    Ambiguity, anyone?

    Categories: Blogs

    AgileCraft 8 Enterprise Agile Tool Launched

    Scrum Expert - Thu, 08/28/2014 - 17:37
    AgileCraft has announced general availability of AgileCraft 8. AgileCraft’s integrated platform provides transparency across the entire software lifecycle, enabling rapid value delivery and better, more predictable results. Built from the top-down to support enterprise agile at scale, the latest version brings new capabilities across all four levels: enterprise, portfolio, program and teams. AgileCraft 8 helps align the whole organization around common goals and objectives, providing actionable views and metrics to everyone touching the product lifecycle. The AgileCraft approach empowers customers to scale with existing tools like Atlassian, TFS, Rally, etc. while adding ...
    Categories: Communities

    Knowledge Sharing

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