Skip to content

Feed aggregator

R: Cohort heatmap of Neo4j London meetup

Mark Needham - Tue, 05/12/2015 - 01:16

A few months ago I had a go at doing some cohort analysis of the Neo4j London meetup group which was an interesting experiment but unfortunately resulted in a chart that was completely illegible.

I wasn’t sure how to progress from there but a few days ago I came across the cohort heatmap which seemed like a better way of visualising things over time.

The underlying idea is still the same – we’ve comparing different cohorts of users against each other to see whether a change or intervention we did at a certain time had any impact.

However, the way we display the cohorts changes and I think for the better.

To recap, we start with the following data frame:

df = read.csv("/tmp/df.csv")
> df %>% sample_n(5)
        rsvp.time person.id                time    date
255  1.354277e+12  12228948 2012-11-30 12:05:08 2012-11
2475 1.407342e+12  19057581 2014-08-06 16:26:04 2014-08
3988 1.421769e+12  66122172 2015-01-20 15:58:02 2015-01
4411 1.419377e+12 165750262 2014-12-23 23:27:44 2014-12
1010 1.383057e+12  74602292 2013-10-29 14:24:32 2013-10

And we need to transform this into a data frame which is grouped by cohort (members who attended their first meetup in a particular month). The following code gets us there:

firstMeetup = df %>% 
  group_by(person.id) %>% 
  summarise(firstEvent = min(time), count = n()) %>% 
  arrange(desc(count))
firstMeetup$date = format(as.Date(firstMeetup$firstEvent), "%Y-%m")
 
countsForCohort = function(df, firstMeetup, cohort) {
  members = (firstMeetup %>% filter(date == cohort))$person.id
 
  attendance = df %>% 
    filter(person.id %in% members) %>% 
    count(person.id, date) %>% 
    ungroup() %>%
    count(date)
 
  allCohorts = df %>% select(date) %>% unique
  cohortAttendance = merge(allCohorts, attendance, by = "date", all.x = TRUE)  
  cohortAttendance[is.na(cohortAttendance) & cohortAttendance$date > cohort] = 0
  cohortAttendance %>% mutate(cohort = cohort, retention = n / length(members), members = n)  
}
 
cohorts = collect(df %>% select(date) %>% unique())[,1]
 
cohortAttendance = data.frame()
for(cohort in cohorts) {
  cohortAttendance = rbind(cohortAttendance,countsForCohort(df, firstMeetup, cohort))      
}
 
monthNumber = function(cohort, date) {
  cohortAsDate = as.yearmon(cohort)
  dateAsDate = as.yearmon(date)
 
  if(cohortAsDate > dateAsDate) {
    "NA"
  } else {
    paste(round((dateAsDate - cohortAsDate) * 12), sep="")
  }
}
 
cohortAttendanceWithMonthNumber = cohortAttendance %>% 
  group_by(row_number()) %>% 
  mutate(monthNumber = monthNumber(cohort, date)) %>%
  filter(monthNumber != "NA") %>%
  filter(!is.na(members)) %>%
  mutate(monthNumber = as.numeric(monthNumber)) %>% 
  arrange(monthNumber)
 
> cohortAttendanceWithMonthNumber %>% head(10)
Source: local data frame [10 x 7]
Groups: row_number()
 
      date n  cohort retention members row_number() monthNumber
1  2011-06 4 2011-06      1.00       4            1           0
2  2011-07 1 2011-06      0.25       1            2           1
3  2011-08 1 2011-06      0.25       1            3           2
4  2011-09 2 2011-06      0.50       2            4           3
5  2011-10 1 2011-06      0.25       1            5           4
6  2011-11 1 2011-06      0.25       1            6           5
7  2012-01 1 2011-06      0.25       1            7           7
8  2012-04 2 2011-06      0.50       2            8          10
9  2012-05 1 2011-06      0.25       1            9          11
10 2012-06 1 2011-06      0.25       1           10          12

Now let’s create our first heatmap.

t <- max(cohortAttendanceWithMonthNumber$members)
 
cols <- c("#e7f0fa", "#c9e2f6", "#95cbee", "#0099dc", "#4ab04a", "#ffd73e", "#eec73a", "#e29421", "#e29421", "#f05336", "#ce472e")
ggplot(cohortAttendanceWithMonthNumber, aes(y=cohort, x=date, fill=members)) +
  theme_minimal() +
  geom_tile(colour="white", linewidth=2, width=.9, height=.9) +
  scale_fill_gradientn(colours=cols, limits=c(0, t),
                       breaks=seq(0, t, by=t/4),
                       labels=c("0", round(t/4*1, 1), round(t/4*2, 1), round(t/4*3, 1), round(t/4*4, 1)),
                       guide=guide_colourbar(ticks=T, nbin=50, barheight=.5, label=T, barwidth=10)) +
  theme(legend.position='bottom', 
        legend.direction="horizontal",
        plot.title = element_text(size=20, face="bold", vjust=2),
        axis.text.x=element_text(size=8, angle=90, hjust=.5, vjust=.5, face="plain")) +
  ggtitle("Cohort Activity Heatmap (number of members who attended event)")

2015 05 11 23 55 56

‘t’ is the maximum number of members within a cohort who attended a meetup in a given month. This makes it easy to see which cohorts started with the most members but makes it difficult to compare their retention over time.

We can fix that by showing the percentage of members in the cohort who attend each month rather than using absolute values. To do that we must first add an extra column containing the percentage values:

cohortAttendanceWithMonthNumber$retentionPercentage = ifelse(!is.na(cohortAttendanceWithMonthNumber$retention),  cohortAttendanceWithMonthNumber$retention * 100, 0)
t <- max(cohortAttendanceWithMonthNumber$retentionPercentage)
 
cols <- c("#e7f0fa", "#c9e2f6", "#95cbee", "#0099dc", "#4ab04a", "#ffd73e", "#eec73a", "#e29421", "#e29421", "#f05336", "#ce472e")
ggplot(cohortAttendanceWithMonthNumber, aes(y=cohort, x=date, fill=retentionPercentage)) +
  theme_minimal() +
  geom_tile(colour="white", linewidth=2, width=.9, height=.9) +
  scale_fill_gradientn(colours=cols, limits=c(0, t),
                       breaks=seq(0, t, by=t/4),
                       labels=c("0", round(t/4*1, 1), round(t/4*2, 1), round(t/4*3, 1), round(t/4*4, 1)),
                       guide=guide_colourbar(ticks=T, nbin=50, barheight=.5, label=T, barwidth=10)) +
  theme(legend.position='bottom', 
        legend.direction="horizontal",
        plot.title = element_text(size=20, face="bold", vjust=2),
        axis.text.x=element_text(size=8, angle=90, hjust=.5, vjust=.5, face="plain")) +
  ggtitle("Cohort Activity Heatmap (number of members who attended event)")

2015 05 12 00 01 55

This version allows us to compare cohorts against each other but now we don’t have the exact numbers which means earlier cohorts will look better since there are less people in them. We can get the best of both worlds by keeping this visualisation but showing the actual values inside each box:

t <- max(cohortAttendanceWithMonthNumber$retentionPercentage)
 
cols <- c("#e7f0fa", "#c9e2f6", "#95cbee", "#0099dc", "#4ab04a", "#ffd73e", "#eec73a", "#e29421", "#e29421", "#f05336", "#ce472e")
ggplot(cohortAttendanceWithMonthNumber, aes(y=cohort, x=date, fill=retentionPercentage)) +
  theme_minimal() +
  geom_tile(colour="white", linewidth=2, width=.9, height=.9) +
  scale_fill_gradientn(colours=cols, limits=c(0, t),
                       breaks=seq(0, t, by=t/4),
                       labels=c("0", round(t/4*1, 1), round(t/4*2, 1), round(t/4*3, 1), round(t/4*4, 1)),
                       guide=guide_colourbar(ticks=T, nbin=50, barheight=.5, label=T, barwidth=10)) +
  theme(legend.position='bottom', 
        legend.direction="horizontal",
        plot.title = element_text(size=20, face="bold", vjust=2),
        axis.text.x=element_text(size=8, angle=90, hjust=.5, vjust=.5, face="plain")) +
  ggtitle("Cohort Activity Heatmap (number of members who attended event)") + 
  geom_text(aes(label=members),size=3)

2015 05 12 00 04 31

What we can learn overall is that the majority of people seem to have a passing interest and then we have a smaller percentage who will continue to come to events.

It seems like we did a better job at retaining attendees in the middle of last year – one hypothesis is that the events we ran around then were more compelling but I need to do more analysis.

Next I’m going to drill further into some of the recent events and see what cohorts the attendees came from.

Categories: Blogs

What Agile Feels Like

Illustrated Agile - Len Lagestee - Tue, 05/12/2015 - 00:00

After many conversations and observations over the past couple of years, it would seem a substantial number of organizations aren’t experiencing a meaningful improvement after a move to Agile. Sure, stories are being written, work is being done within sprints, and planning sessions are being facilitated. Perhaps a scaled framework has been introduced, full of promise and opportunity. The teams seem be doing everything right…but something still feels amiss. Beyond the mechanics, the hype, and the marketing of Agile, the dysfunctions of the past still linger below the surface.

When I encounter organizations frustrated with the lack of real transformational change I often respond by asking a simple question. “Well, what does it feel like?” Typical responses are “It doesn’t feel any different from before.” or all too frequent, “It feels worse than before, we’re thinking of going back.”

What should an Agile organization “feel” like? Here is a list of just a few of the things I look for in an organization with agility embedded in their DNA:

Illumination. Agile will often reveal long-standing dysfunctions in your organization. There is a feeling of openness and honesty about the bad habits accumulated over time. The opportunity to continuously reflect, adjust, and evolve is embraced. By allowing all the “dark corners” of the organization to be revealed, there may a feeling of being unsettled or uncomfortable as well. This is a good thing. As a colleague of mine always says, “Become comfortable with being uncomfortable.”

Decisive. There is a feeling that decisions are made quickly and without formal “toll-gates” or unnecessary approvals. Bureaucracy dissolves. Command-and-control leadership fades away. It should feel as if the frontline project or product teams are making real-time decisions with the power of the enterprise behind them.

Connective. Communication is flowing through the organization. Phase gates and approvals are replaced with opportunities to design and build things together. When an Agile team states, “We need to check with the business”, I’m pretty sure things are not feeling very agile. There is no such thing as “the business” and “technology”…we are all the business and we are all technology these days.

Self-healing. There is a tangible sense that teams and departments are recognizing their own pain points and is fixing them in real-time. No need to wait for a leader to tell us to change or for an outside coach to come in and tell us what is broken. The community of practitioners are shaping their own workplace while still aligned to the vision of the enterprise.

Resilient. Reorganizations and “change events” become a thing of the past as change is built into the DNA of the organization. This article details a few of the ways emergent organizations are building resiliency into their systems. This resiliency allows us to, as Eric Ries puts it, “actively pursue the unknown.”

Productive. There is a feeling that we are delivering more features more quickly. This often means removing items from our long list of never completed projects and focusing on a few key products or features. This often means having cross-functional teams with everything in place to deliver fully functional product to our customers. No more allocating people across multiple teams or projects.

Festive. While I wouldn’t expect every day to feel like Mardi Gras, a celebratory feel should begin to ripple through the organization. When a group of people are aligned to a common purpose and begin to delight their customers with amazing products and features, you can’t help but throw a few parties.

For many organizations, obtaining this “feeling” will take significant work. Large companies or older organizations will need extra care to release their organizational scar tissue. Are you up for it?

Becoming a Catalyst - Scrum Master Edition

The post What Agile Feels Like appeared first on Illustrated Agile.

Categories: Blogs

How to improve Scrum team performance with Kanban

Xebia Blog - Mon, 05/11/2015 - 22:22
This blogpost has been a collaborative effort between Jeroen Willemsen and Jasper Sonnevelt

In this post we will take a look at a real life example of a Scrum team transitioning to Kanban. We will address a few pitfalls and discuss how to circumvent those. With this we provide additional insights to advance your agile way of working.

The example

At the time we joined this project, three Scrum-teams worked together to develop a large software product. The teams shared a Product Owner (PO) and backlog and just had their MVP released. Now, bug-reports started coming in and the Scrum-teams faced several problems:

  • The developers were making a lot of progress per sprint, so the PO had to put a lot of effort in the backlog to create a sufficiently sized work inventory.New bugs came to light as the product started to become adopted. Filing and fixing these bugs and monitoring the progress was taking a lot of effort from the PO. Solving each bug in the next sprint reduced the team's response time.
  • Prioritizing the bug-fixing and the newly requested features became hard as the PO had to many stakeholders to manage.
  • The Product Owner saw Kanban as a possible solution to these problems. He convinced the team to implement it in an effort to deal with these problems and to provide a better way of working.

The practices that were implemented included:

  • No more sprint replenishment rhythm (planning & backlog refinement);
  • A Work in Progress (WIP) limit.

As a result the backlog quality started to deprecate. Less information was written down about a story and developers did not take the time to ask the right questions towards the PO. The WIP limit maximised the amount of work the team could take on. This made them focus on the current, sometimes unclear and too complex stories. Because of this developers would keep working on their current tasks, making assumptions along the way. These assumptions could sometimes lead to conflicting insights as developers would collaborate on stories, while at the same time being influenced by different stakeholders. This resulted in misalignment.

All of these actions resulted in a lower burn down rate, less predictability and therefore nervous stakeholders. And after a few weeks, the PO decided to stop the migration to Kanban, and go back to Scrum.

However, the latter might not have been necessary for the team to be successful. After all, it is about how you implement Kanban. There were a few key elements missing for instance. In our experience, teams that are successful (would) have also implemented:

  • Forecasting based on historical data and simulations: Scrum teams use Planning Poker and Velocity to make predictions about the amount of work they will be able to do in a sprint. When sprint cadence is let go this will become more difficult. Practices in the Kanban Method tell us that by using historical data in simulations, the same and probably more predictability can be achieved.
  • Policies for prioritizing, WIP monitoring and handover criteria: Kanban demands a very high amount of discipline from all participants. Policies will help here. In the case of this team, it would have benefited greatly from having clear defined policies about priorities and prioritization. For instance: Who can (and is allowed to) prioritize? How can the team see what has most priority? Are there different classes of service we can identify? And how do we treat those? The same holds for WIP-limits and handover criteria. We always use a Definition of Ready and Definition of Done in Scrum teams. Keeping these in a Kanban team is a very good practice.
  • A feedback cycle to review data and process on a regular basis: Where Scrum demands a retrospective after every sprint, Kanban does not explicitly define such a thing. Kanban only dictates that you should implement feedback loops. When an organization starts implementing Kanban it is key that they do review the implementation, data and process at a regular basis. This is crucial during the first weeks: all participants will have to get used to the new way of working. Policies should be reviewed as well, as they might need adjustments to facilitate the team in having an optimized workflow.

The hard thing about Kanban

What most people think and see when talking about Kanban is introducing WIP limits to their board, adding columns (other than To do, In Progress, Done) and stop using sprints. And herein lies one of the problems. For organizations that are used to working with Scrum letting go of sprints is a very unnatural thing to do. It feels like letting go of predictability and regular feedback. And instead of making the organization a bit better people feel like they have just taken a step back.

The hard thing about Kanban is that it doesn't provide you with a clear cut solution to your problems like Scrum does. Kanban is a method that helps you fix the problems in your organization in a way that best fits your context. For instance: it tells you to visualize a lot of things but only provides examples of what you could visualize. Typically teams and organizations visualize their process and work(types).

To summarize:

  • Kanban uses the current process and doesn't enforce a process of it's own. Therefore it demands a higher degree of discipline, both from the team-members and the the rest of the organization. If you are not aware of this the introduction of Kanban will only lead to chaos.
  • Kanban doesn't say anything about (To Do column) replenishment frequency or demo frequency.

Recommendations:

  • Implement forecasting based on historical data and simulations, policies for prioritizing, WIP limits and handover criteria and a feedback cycle to review data and process on a regular basis.
  • Define clear policies about how to collaborate. This will help create transparency and predictability.
  • The Scrum ceremonies happen in a rhythm that is very easy to understand and learn for stakeholders. Keep that mind when designing Kanban policies.

 

Categories: Companies

User Story Normalization

Scrum Expert - Mon, 05/11/2015 - 17:35
Using Story points is a technique used by Scrum team to evaluate the relative size of user stories. If this technique works fine for single teams, it might be more problematic when multiple teams are involved. In this article, Paul Raymond explains why user story normalization is needed in contexts where multiple Scrum teams cooperate on the same user stories. Paul Raymond, Inflectra Corporation, http://www.inflectra.com/ Traditional software development estimating techniques are slow, long lasting exercises and as such are totally unsuited to Agile processes. New methods of estimating have emerged which fit ...
Categories: Communities

An Experience That Sticks

Rally Agile Blog - Mon, 05/11/2015 - 15:30

Aha moments. Diverse conversations and insights. Engaging workshops. Extraordinary stories. And most important, action items to take back to your day job.

When people experience something truly unique at an event, it sticks with them.

Our annual RallyON!™ 2015 Agile conference is that kind of event, and it’s happening June 15–17 in Phoenix, Arizona. The full agenda is now live and features more than 60 sessions chock full of good stories, keen observations, best practices, and hands-on activities that align with our seven distinct tracks.

While you can’t possibly attend everything, you can filter the agenda by track to find sessions most relevant and interesting to you. Some suggestions:

Speaking of good stories, our inspiring keynote speakers, including Dan Pink, are sure to get you thinking, laughing, and learning about how to keep up with the new pace of change.

No matter your role, your RallyON 2015 experience will get you fired up to create positive change throughout your organization.

Morgan Campbell
Categories: Companies

SonarQube User Conference in Paris

Sonar - Mon, 05/11/2015 - 12:12

We are very happy to announce that we are organizing our first Paris SonarQube User Conference, on June 10, 2015 from 9:30 a.m. until 2 p.m. at the Salons de l’Aéro-Club, 6 Rue Galilée in the 16th arrondissement.

This conference offers a great opportunity to meet other members of the community and compare notes on your experiences with the platform. We’ll also discuss new features, and the platform road map. We’re expecting many members of the community, including speakers from our global customer base and partners, and of course the SonarSource Team. We are expecting heated debate around the adoption and perspectives for SonarQube, as well as some insights on the paradigm shift in managing Technical Debt!

The program will also feature talks from Jean-Louis Letouzey (www.sqale.org) on understanding and leveraging the SQALE methodology, and Jean-Marc Prieur from Microsoft (http://blogs.msdn.com/b/jmprieur/) on the integration with Visual Studio & TFS.

To register for the event, simply send an email to kristi.karu At sonarsource.com. We are looking forward to meeting you there!

Categories: Open Source

Scrum funktioniert bei uns nicht

Scrum 4 You - Mon, 05/11/2015 - 08:25

Die meisten Unternehmen, die uns derzeit kontaktieren, haben bereits Erfahrungen mit Scrum gemacht. Warum rufen sie uns an, wenn sie doch schon wissen, wie es geht? Nun, nachdem diese Gespräche die „können wir schon … wissen wir schon …“-Phase durchlaufen haben, fällt dann meistens der Satz: „Scrum funktioniert bei uns nicht.“ Warum ist das so? Es gibt doch viele Firmen, die mit Scrum erfolgreich sind – was läuft bei den anderen falsch?

Wie wir in diversen Diskussionen unter Kollegen immer wieder feststellen: Scrum ist ein Rahmenwerk, nicht mehr und nicht weniger. Wenn Scrum funktionieren soll, muss es mit Werten gefüllt werden und das kann das Rahmenwerk nun mal nicht selbst – dazu braucht es die Menschen, die damit arbeiten. Gleichzeitig sollte dieses Rahmenwerk aber auch nicht so verbogen werden, bis es sich an die natürlich gewachsene Struktur des Unternehmens angepasst hat und im Prinzip alles so weiterläuft wie bisher.

Die natürliche Abwehrreaktion des Systems

Das ist jedoch die natürliche Reaktion, sobald Scrum in einem Unternehmen eingeführt wird. Im Rahmen einer schon bisher dysfunktionalen Meetingkultur werden nun neue Meetings abgehalten und es wird versucht, in Iterationen zu arbeiten. So weit, so gut. Vielleicht schickt man noch ein paar Leute in die Ausbildung zum Product Owner oder ScrumMaster und besetzt die Positionen. Aus den Jahreszielen werden noch schnell Gruppenziele gemacht und jetzt will man sich zufrieden zurücklehnen können, von unendlichen Geschwindigkeitszuwächsen träumen und die selbstorganisierten Teams alle Probleme selbstständig lösen lassen (aber bitte nicht gegen den Willen des Teamleiters, sonst fühlt er sich gekränkt). Was passiert ist: Es wurde eine zusätzliche Schicht eingezogen, aber kein konkretes Problem gelöst. Ich kann diesen Wunsch gut nachvollziehen, weil ich den Fehler selbst gemacht habe – aber es funktioniert einfach nicht. Scrum per se löst keine Probleme. Es zeigt nur, wo Änderungen notwendig sind.

Woran erkennen wir, dass sich trotzdem etwas bewegt?

Wenn nach der Einführung von Scrum plötzlich die Teams keine Zeit mehr zum Arbeiten haben, weil sie in noch mehr Meetings als vorher sitzen, dann liegt es nicht daran, dass Scrum so meetingintensiv ist. Es liegt daran, dass Scrum keine zusätzlichen Meetings impliziert. Scrum ist meetingtechnisch vollständig – schmeißen Sie also alle anderen Meetings raus und lassen Sie Ihre Leute arbeiten. Wenn Sie nach der Einführung von Scrum plötzlich Leute aufschreien hören, dass das so nicht geht, Kompetenzen verletzt werden und Unsicherheiten entstehen, dann arbeiten Sie mit den Leuten an Ihren neuen Rollen oder holen Sie externe Unterstützung.

Letztendlich ist das Aufkommen dieser “Probleme” nicht schlecht. Es sind einfach nur Indikatoren dafür, wie weit man auf dem Weg der Veränderung einer Systemkultur vorangekommen ist. Diese Indikatoren anzusehen mag schmerzlich sein, aber der Schmerz geht vorbei, sofern man das Problem sieht und an einer Lösung arbeitet. Scrum bewirkt einen Paradigmenwechsel in einem existierenden System. Und jeder Paradigmenwechsel ist mit einer Form von Schmerz verbunden: mit dem Schmerz, das Alte aufzugeben und etwas Neues anzunehmen. Wenn Ihre Leute aufschreien und unzufrieden mit dem Status Quo sind, freuen Sie sich!

Was Sie gerade sehen, ist wertlos gebundene menschliche Energie, die frei wird. Mit dieser Energie können Sie nun einen Wandel einleiten, der zu einer wirklichen Veränderung des Gesamtsystem beiträgt. Bleiben Sie dran, immerhin wissen Sie jetzt, wo Ihre Ansatzpunkte liegen, wo Sie die nächsten Schritte setzen müssen auf dem Weg zu einer gemeinsamen agilen Kultur.

Categories: Blogs

Bounded Authority in an Agile World

Much is written about self-organization in an Agile world.  For some, the notion of self-organizing teams scares folks.  Does this mean that a team can decide everything?  Of course, the short answer is no.  I suggest the concern is due to not having boundaries for self-organization.  I call the framework for this context, bounded authority.  Bounded authority is defined by the information, experience, and decisions a group has control over within their context. Within a hierarchical structure of a company, bounded authority can work at multiple levels.  For simplicity, let us focus on the team level, middle management level, and senior management level. 
But first, let’s spend a few minutes to define what self organization means at a team level.  A self organizing team is a group of motivated individuals who have a common purpose, owns their work, and has the authority to make decisions on the work they are doing.  Within an Agile context, the goal is to push decision making to the lowest possible level and to the level in which the most information and experience dwells.  For a Scrum team, they self organize around the work that has been prioritized by the Product Owner that lives within the product backlog.  Once that work is available at the team level, the team has the authority to make architecture, design, programming, and coding decisions and can self-organize around the work.

So if the team’s work is defined within the product backlog, what does middle management do?  Can they assign work to the team?  The short answer is that this is not within the bounded authority for the middle management since the team gets their work from the product backlog.  While the team self-organizes around the work, middle management helps optimize flow for their teams and enables the team to be its most effective. By optimizing flow for their organization and teams, this includes removing impediments for their teams to enable them to work faster.   Middle Management may also focus on helping their teams with their career management goals. 
Above the middle management are the senior management (or executives).  Should they be reaching down and telling the teams how to build the product?  To answer this question, another question should be answered.  Does senior management have more knowledge and experience in what should be built or is this knowledge most known at the team level?  While the answer is the latter (team level), senior management has a bounded authority and duty to provide a strategy for the organization. This means they must help the teams understand the strategy and help them align strategy with their work.
Another example of bounded authority is relating it to your requirements hierarchy.  Consider who has the authority over the strategy, who has the authority over the ideas, who has the authority over the user stories.  This could be senior management who makes the decision to decide the top strategies, the chief product owners who makes the decision on prioritizing the ideas, the product owner who owns the decision to prioritize the backlog, and the and team who makes the decision on how to self-organize around the user stories.     
The key to bounded authority is that each level knows what they can self-organize around, what they have the authority to change, and areas in which they can make decisions.  Within an Agile context, that level of ownership and decision-making should be pushed down to the lowest possible level.  This can be an exercise that occurs at both the senior management and middle management levels. 
Categories: Blogs

R: Neo4j London meetup group – How many events do people come to?

Mark Needham - Sun, 05/10/2015 - 00:33

Earlier this week the number of members in the Neo4j London meetup group creeped over the 2,000 mark and I thought it’d be fun to re-explore the data that I previously imported into Neo4j.

How often do people come to meetups?

library(RNeo4j)
library(dplyr)
 
graph = startGraph("http://localhost:7474/db/data/")
 
query = "MATCH (g:Group {name: 'Neo4j - London User Group'})-[:HOSTED_EVENT]->(event)<-[:TO]-({response: 'yes'})<-[:RSVPD]-(profile)-[:HAS_MEMBERSHIP]->(membership)-[:OF_GROUP]->(g)
         WHERE (event.time + event.utc_offset) < timestamp()
         RETURN event.id, event.time + event.utc_offset AS eventTime, profile.id, membership.joined"
 
df = cypher(graph, query)
 
> df %>% head()
  event.id    eventTime profile.id membership.joined
1 20616111 1.309372e+12    6436797      1.307285e+12
2 20616111 1.309372e+12   12964956      1.307275e+12
3 20616111 1.309372e+12   14533478      1.307290e+12
4 20616111 1.309372e+12   10793775      1.307705e+12
5 24528711 1.311793e+12   10793775      1.307705e+12
6 29953071 1.314815e+12   10595297      1.308154e+12
byEventsAttended = df %>% count(profile.id)
 
> byEventsAttended %>% sample_n(10)
Source: local data frame [10 x 2]
 
   profile.id  n
1   128137932  2
2   126947632  1
3    98733862  2
4    20468901 11
5    48293132  5
6   144764532  1
7    95259802  1
8    14524524  3
9    80611852  2
10  134907492  2

Now let’s visualise the number of people that have attended certain number of events:

ggplot(aes(x = n), data = byEventsAttended) + 
  geom_bar(binwidth = 1, fill = "Dark Blue") +
  scale_y_continuous(breaks = seq(0,750,by = 50))

2015 05 09 01 15 02

Most people come to one meetup and then there’s a long tail after that with fewer and fewer people coming to lots of meetups.

The chart has lots of blank space due to the sparseness of people on the right hand side. If we exclude any people who’ve attended more than 20 events we might get a more interesting visualisation:

ggplot(aes(x = n), data = byEventsAttended %>% filter(n <= 20)) + 
  geom_bar(binwidth = 1, fill = "Dark Blue") +
  scale_y_continuous(breaks = seq(0,750,by = 50))
2015 05 09 01 15 36

Nicole suggested a more interesting visualisation would be a box plot so I decided to try that next:

ggplot(aes(x = "Attendees", y = n), data = byEventsAttended) +
  geom_boxplot(fill = "grey80", colour = "Dark Blue") +
  coord_flip()

2015 05 09 22 31 20

This visualisation really emphasises that the majority are between 1 and 3 and it’s much less obvious how many values there are at the higher end. A quick check of the data with the summary function reveals as much:

> summary(byEventsAttended$n)
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
  1.000   1.000   2.000   2.837   3.000  69.000


Now to figure out how to move that box plot a bit to the right :)

Categories: Blogs

More tips for CST Aspirants

Scrum Breakfast - Sat, 05/09/2015 - 10:49
What does it take to become a Certified Scrum Trainer (CST)? Passion and Energy. You should stand out from the crowd!

Aspirant: How high do we have to climb?
TAC: What we really want is someone who can leap tall buildings in a single bound!The Scrum Alliance Trainer Acceptance Committee held its first ever workshop for CST Aspirants last week at SGPHX, the Phoenix Scrum Gathering. This gave candidates a chance to ask questions and understand what is really expected of a CST to get through the final examination.

The answers to two questions really stood out for me in this workshop:

  • Why do I have to submit my own learning materials?
  • How many students must I have taught?


Why do you have to submit your own learning materials?Many Aspirants today work for a company that has already created a "deck" for teaching Scrum. I am told that Scrum.org even requires their trainers to train to a standardized deck. Why reinvent the wheel? 
If an Aspirant is using someone else's materials, here is a typical conversation during the final interview:
  • Examiner: What does this diagram on page 35 mean?
  • Aspirant: <dances around the question without really answering it>
  • Examiner: Try again. What does it really mean?
  • Aspirant: I'm not sure. It's something the company put in, but I don't really use it in my course.
A CST must know their stuff! A CST should not be training materials that they do not understand or support fully. If you don't create it, it's almost impossible to learn it well enough to teach from it effectively and without blind spots.
How many students must you teach?The Scrum Alliance requires an Aspirant to have taught at least 100 students in CSM-like context (2 day course). This should demonstrate that you are capable of doing the job of a CST. 
Does training 100 students guarantee that you will be accepted? No.
The Scrum Alliance wants its trainers to come from the top 1%. That top 1% are the people who motivate and convince others to want to do Scrum and do it well. You're job is to convince the TAC that you belong there already, so all they have to do is recognize your accomplishment!
A CST is not merely a trainer. A CST is an ambassador of Scrum. So the criteria on the Scrum Alliance website are perhaps best to be understood not as acceptance criteria, but as exclusion criteria. If you don't meet these criteria, don't bother applying. If your objective is simply to satisfy the absolute minimum requirements necessary, then you probably haven't understood what being a CST is really about, and are therefore unlikely to pass.What does it take to become a CST?Above all else, perseverance! Don't give up. Not everyone makes on the first try. I needed four tries, an extreme case, to be sure, but many need two tries to get through, and some very good trainers even needed three. Passion, energy, and perseverance! 
P.S. To my padawans who came up for evaluation in Phoenix: Congratulations and high fives to Joe Justice! Joe needed two tries to get through. And to Lizzie Morris, I say don't give up! Both of you are awesome trainers who deserve to be recognized as such!
P.P.S. Are you a CST Aspirant? If are on the path to becoming CST, check out our network

Categories: Blogs

Beat the Transformation Odds

If you’re currently considering or have already taken on an organizational transformation, new research from McKinsey provides useful insights to triple your odds of success. Substantial organizational change comes with a chasm of risk; however, McKinsey’s report suggests a repeatable formula to help you cross safely. Following their recommendations can increase your success rate up to 79%, based […]

The post Beat the Transformation Odds appeared first on Blog | LeanKit.

Categories: Companies

Welcome to the New Lean

If you’ve been to business school, or are at all familiar with business history, you’ll know that Lean was a big, big thing in the 1980s and ‘90s. Western manufacturing companies were being decimated by their Japanese rivals, especially Toyota, and they were trying everything they could to regain their competitive edge. Many flavors of […]

The post Welcome to the New Lean appeared first on Blog | LeanKit.

Categories: Companies

Business Flow: Watch the Baton, Not the Runner

Imagine you’re at the Olympic Games, watching the 4x400m relay race. While one runner carries the baton around the track, the other three runners stand around waiting. If we ran the relay race like most of us run our businesses, it would look very different. Each of the idle runners would be running three other […]

The post Business Flow: Watch the Baton, Not the Runner appeared first on Blog | LeanKit.

Categories: Companies

Knowledge Sharing on Agile Projects: Absent or Abundant?

Leading Answers - Mike Griffiths - Sat, 05/09/2015 - 03:18
Knowledge transfer and sharing on agile teams differs from traditional approaches in both form and the internal vs external focus. Agile teams produce few of the traditional knowledge transfer documents yet their daily practices focus on knowledge transfer. While agile... Mike Griffiths
Categories: Blogs

Understanding the 'sender' in segues and use it to pass on data to another view controller

Xebia Blog - Fri, 05/08/2015 - 23:59

One of the downsides of using segues in storyboards is that you often still need to write code to pass on data from the source view controller to the destination view controller. The prepareForSegue(_:sender:) method is the right place to do this. Sometimes you need to manually trigger a segue by calling performSegueWithIdentifier(_:sender:), and it's there you usually know what data you need to pass on. How can we avoid adding extra state variables in our source view controller just for passing on data? A simple trick is to use the sender parameter that both methods have.

The sender parameter is normally used by storyboards to indicate the UI element that triggered the segue, for example an UIButton when pressed or an UITableViewCell that triggers the segue by selecting it. This allows you to determine what triggered the segue in prepareForSegue:sender:, and based on that (and of course the segue identifier) take some actions and configure the destination view controller, or even determine that it shouldn't perform the segue at all by returning false in shouldPerformSegueWithIdentifier(_:sender:).

When it's not possible to trigger the segue from a UI element in the Storyboard, you need to use performSegueWithIdentifier(_:sender:) instead to manually trigger it. This might happen when no direct user interaction should trigger the action of some control that was created in code. Maybe you want to execute some additional logic when pressing a button and after that perform the segue. Whatever the situation is, you can use the sender argument to your benefit. You can pass in whatever you may need in prepareForSegue(_:sender:) or shouldPerformSegueWithIdentifier(_:sender:).

Let's have a look at some examples.

Screen Shot 2015-05-08 at 23.25.37

Here we have two very simple view controllers. The first has three buttons for different colors. When tapping on any of the buttons, the name of the selected color will be put on a label and it will push the second view controller. The pushed view controller will set its background color to the color represented by the tapped button. To do that, we need to pass on a UIColor object to the target view controller.

Even though this could be handled by creating 3 distinct segues from the buttons directly to the destination view controller, we chose to handle the button tap ourselves and the trigger the segue manually.

You might come up with something like the following code to accomplish this:

class ViewController: UIViewController {

    @IBOutlet weak var label: UILabel!

    var tappedColor: UIColor?

    @IBAction func tappedRed(sender: AnyObject) {
        label.text = "Tapped Red"
        tappedColor = UIColor.redColor()
        performSegueWithIdentifier("ShowColor", sender: sender)
    }

    @IBAction func tappedGreen(sender: AnyObject) {
        label.text = "Tapped Green"
        tappedColor = UIColor.greenColor()
        performSegueWithIdentifier("ShowColor", sender: sender)
    }

    @IBAction func tappedBlue(sender: AnyObject) {
        label.text = "Tapped Blue"
        tappedColor = UIColor.blueColor()
        performSegueWithIdentifier("ShowColor", sender: sender)
    }

    override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
        if segue.identifier == "ShowColor" {
            if let colorViewController = segue.destinationViewController as? ColorViewController {
                colorViewController.color = tappedColor
            }
        }
    }

}

class ColorViewController: UIViewController {

    var color: UIColor?

    override func viewDidLoad() {
        super.viewDidLoad()

        view.backgroundColor = color
    }

}

We created a state variable called tappedColor to keep track of the color that needs to be passed on. It is set in each of the action methods before calling performSegueWithIdentifier("ShowColor", sender: sender) and then read again in prepareForSegue(_:sender:) so we can pass it on to the destination view controller.

The action methods will have the tapped UIButtons set as the sender argument, and since that's the actual element that initiated the action, it makes sense to set that as the sender when performing the segue. So that's what we do in the above code. But since we don't actually use the sender when preparing the segue, we might as well pass on the color directly instead. Here is a new version of the ViewController that does exactly that:

class ViewController: UIViewController {

    @IBOutlet weak var label: UILabel!

    @IBAction func tappedRed(sender: AnyObject) {
        label.text = "Tapped Red"
        performSegueWithIdentifier("ShowColor", sender: UIColor.redColor())
    }

    @IBAction func tappedGreen(sender: AnyObject) {
        label.text = "Tapped Green"
        performSegueWithIdentifier("ShowColor", sender: UIColor.greenColor())
    }

    @IBAction func tappedBlue(sender: AnyObject) {
        label.text = "Tapped Blue"
        performSegueWithIdentifier("ShowColor", sender: UIColor.blueColor())
    }

    override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
        if segue.identifier == "ShowColor" {
            if let colorViewController = segue.destinationViewController as? ColorViewController {
                colorViewController.color = sender as? UIColor
            }
        }
    }

}

This allows us to get rid of our extra tappedColor variable.

It might seem to (and perhaps it does) abuse the sender parameter though, so use it with care and only where appropriate. Be aware of the consequences; if some other code or some element in a Storyboard triggers the same segue (i.e. with the same identifier), then the sender might just be an UI element instead of the object you expected, which will lead to unexpected results and perhaps even crashes when you force cast the sender to something it's not.

You can find the sample code in the form of an Xcode project on https://github.com/lammertw/SegueColorSample.

Categories: Companies

CEO Chris Hefley Explains New Logo and Brand

I’m excited to announce LeanKit’s new logo and brand. This marks a significant milestone in our journey, providing an opportunity to reflect on everything that the original LeanKit brand stood for and everything that we aspire to become. Our Journey So Far Since our founding in 2009, LeanKit has experienced tremendous growth. We’ve become a […]

The post CEO Chris Hefley Explains New Logo and Brand appeared first on Blog | LeanKit.

Categories: Companies

Task Management for Teams

J.D. Meier's Blog - Fri, 05/08/2015 - 17:01

I’m a fan of monthly plans for meaningful work.

Whether you call it a task list or a To-Do list or a product backlog, it helps to have a good view of the things that you’ll invest your time in.

I’m not a fan of everybody trying to make sense of laundry lists of cells in a spreadsheet.

Time changes what’s important and it’s hard to see the forest for the trees, among rows of tasks that all start to look the same.

One of the most important things I’ve learned to do is to map out work for the month in a more meaningful way.

It works for individuals.  It works for teams.  It works for leaders.

It’s what I’ve used for Agile Results for years on projects small and large, and with distributed teams around the world.  (Agile Results is my productivity method introduced in Getting Results the Agile Way.)

A picture is worth a thousand words, so let’s just look at a sample output and then I’ll walk through it:

clip_image002

What I’ve found to be the most effective is to focus on a plan for the month – actually take an hour or two the week before the new month.  (In reality, I’ve done this with teams of 10 or more people in 30 minutes or less.  It doesn’t take long if you just dump things fast on the board, and just keep asking people “What else is on our minds.”)

Dive-in at a whiteboard with the right people in the room and just list out all the top of mind, important things – be exhaustive, then prioritize and prune.

You then step back and identify the 3 most important outcomes (3 Wins for the Month.)

I make sure each work item has a decent name – focused on the noun – so people can refer to it by name (like mini-initiatives that matter.)

I list it in alphabetical by the name of the work so it’s easy to manage a large list of very different things.

That’s the key.

Most people try to prioritize the list, but the reality is, you can use each week to pick off the high-value items.   (This is really important.  Most people spend a lot of time prioritizing lists, and re-prioritizing lists, and yet, people tend to be pretty good prioritizing when they have a quick list to evaluate.   Especially, if they know the priorities for the month, and they know any pressing events or dead-lines.   This is where clarity pays off.)

The real key is listing the work in alphabetical order so that it’s easy to scan, easy to add new items, and easy to spot duplicates.

Plus, it forces you to actually name the work and treat it more like a thing, and less like some fuzzy idea that’s out there.

I could go on and on about the benefits, but here are a few of the things that really matter:

  1. It’s super simple.   By keeping it simple, you can actually do it.   It’s the doing, not just the knowing that matters in the end.
  2. It chops big work down to size.   At the same time, it’s easy to quickly right-size.  Rather than bog down in micro-management, this simple list makes it easy to simply list out the work that matters.
  3. It gets everybody in the game.   Everybody gets to look at a whiteboard and plan what a great month will look like.  They get to co-create the journey and dream up what success will look like.   A surprising thing happens when you just identify Three Wins for the Month.

I find a plan for the month is the most useful.   If you plan a month well, the weeks have a better chance of taking care of themselves.   But if you only plan for the week or every two weeks, it’s easy to lose sight of the bigger picture, and the next thing you know, the months go by.  You’re busy, things happen, but the work doesn’t always accrue to something that matters.

This is a simple way to have more meaningful months.

I also can’t say it enough, that it’s less about having a prioritized list, and more about having an easy to glance at map of the work that’s in-flight.   I’m glad the map of the US is not a prioritized list by states.  And I’m glad that the states are well named.  It makes it easy to see the map.  I can then prioritize and make choices on any trip, because I actually have a map to work from, and I can see the big picture all at once, and only zoom in as I need to.

The big idea behind planning tasks and To-Do lists this way is to empower people to make better decisions.

The counter-intuitive part is first exposing a simple view of the map of the work, so it’s easy to see, and this is what enables simpler prioritization when you need it, regardless of which prioritization you use, or which workflow management tool you plug in to.

And, nothing stops you from putting the stuff into spreadsheets or task management tools afterwards, but the high-value part is the forming and storming and conforming around the initial map of the work for the month, so more people can spend their time performing.

May the power of a simple information model help you organize, prioritize, and optimize your outcomes in a more meaningful way.

If you need a deeper dive on this approach, and a basic introduction to Agile Results, here is a good getting started guide for Agile Results in action.

Categories: Blogs

Customer Spotlight: Aternity

Rally Agile Blog - Thu, 05/07/2015 - 21:00

Occasionally, we like to share the stories of Rally customers who are doing cool and interesting things.

Aternity is one of those customers — an expert-level Agile shop that has mastered the art and science of keeping iterations and releases on track.

Beyond Speeds and Feeds

The end-user experience has broadened and fragmented. It’s a brave new world of laptops, mobile devices, software as a service, and the cloud — leaving IT departments scrambling to rein in the complexity.

That’s where Aternity comes in. Their solutions help IT departments maintain performance and security amid the disruption by monitoring the end-user experience on any device — physical, virtual, or mobile. Aternity's solutions are so effective, they've earned the company four dozen awards in five years.

Crossing an Ocean with Agile

Aternity’s R&D department is based in Hod Hasharon, Israel — more than 5,000 miles from company headquarters in Westborough, Massachusetts. That makes for a seven-hour time difference between R&D and the product team.

Aternity didn’t have a problem with the distance. R&D teams had used Scrum practices since 2011, meeting for daily standups and collaborating closely with product owners to align the work. It was their Agile tool that was giving them headaches.

As development lead Sigal Korczyn says, “R&D started using another project management tool to manage the work, but people very quickly abandoned it. As a result, when nearing a milestone, it became very challenging to create a single view representing the delivery status.”

It’s a well-known fact that you can’t force developers to use tools they don’t want to use. Aternity had to find a solution everyone could get behind. The company chose the Rally platform to provide cross-team visibility into iterations and releases, helping them move faster.

Read the case study.

Jen Page
Categories: Companies

Agile Israel, Tel Aviv, Israel, June 9-10 2015

Scrum Expert - Thu, 05/07/2015 - 15:01
Agile Israel is a two-day conference that discusses Agile, Scrum and Lean topics. It aims to attract Agile Managers, Scrum Masters, Product Owners and Coaches to discuss and network around these themes. The second day is dedicated to tutorials and workshops. In the agenda of Agile Israel you can find topics like “Recharging/Boosting your Agility”, “Create Leaders at Every Level”, “Dealing with Shifting Priorities using Lean/Kanban Flow, WIP Limits and Capacity Allocation”, ” AdvanScrum”, “Feature discovery through Design Thinking”, “M-Agile – Best practices for successful Mobile Agile”, “BDD from the Trenches”, ...
Categories: Communities

Knowledge Sharing


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