Skip to content

Feed aggregator

R: Date for given week/year

Mark Needham - Sat, 07/11/2015 - 00:01

As I mentioned in my last couple of blog posts I’ve been looking at the data behind this blog and I wanted to plot a chart showing the number of posts per week since the blog started.

I started out with a data frame with posts and publication date:

> library(dplyr)
> df = read.csv("posts.csv")
> df$date = ymd_hms(df$date)
> df %>% sample_n(10)
                                                                                title                date
538                                    Nygard Big Data Model: The Investigation Stage 2012-10-10 00:00:36
341                                                            The read-only database 2011-08-29 23:32:26
1112                                  CSS in Internet Explorer - Some lessons learned 2008-10-31 15:24:51
143                                                       Coding: Mutating parameters 2010-08-26 07:47:23
433  Scala: Counting number of inversions (via merge sort) for an unsorted collection 2012-03-20 06:53:18
618                                    neo4j/cypher: SQL style GROUP BY functionality 2013-02-17 21:05:27
1111                                 Testing Hibernate mappings: Setting up test data 2008-10-30 13:24:14
462                                       neo4j: What question do you want to answer? 2012-05-05 13:20:41
1399                                       Book Club: Design Sense (Michael Feathers) 2009-09-29 14:42:29
494                                    Bash Shell: Reusing parts of previous commands 2012-07-05 23:42:35

The first step was to add a couple of columns representing the week and year for the publication date. The ‘lubridate’ library came in handy here:

byWeek = df %>% 
  mutate(year = year(date), week = week(date)) %>% 
  group_by(week, year) %>% summarise(n = n()) %>% 
  ungroup() %>% arrange(desc(n))
> byWeek
Source: local data frame [352 x 3]
   week year  n
1    33 2008 14
2    35 2008 11
3    53 2012 11
4     9 2013 10
5    12 2013  9
6    21 2009  9
7    22 2009  9
8    38 2013  9
9    40 2008  9
10   48 2012  9
..  ...  ... ..

The next step is to calculate the start date of each of those weeks so that we can plot the counts on a continuous date scale. I spent a while searching how to do this before realising that the ‘week’ function I used before can set the week for a given data as well. Let’s get to work:

calculate_start_of_week = function(week, year) {
  date <- ymd(paste(year, 1, 1, sep="-"))
  week(date) = week
> calculate_start_of_week(c(1,2,3), c(2015,2014,2013))
[1] "2015-01-01 UTC" "2014-01-08 UTC" "2013-01-15 UTC"

And now let’s transform our data frame and plot the counts:

ggplot(aes(x=start_of_week, y=n, group=1), 
       data = byWeek %>% mutate(start_of_week = calculate_start_of_week(week, year))) + 

2015 07 10 22 43 54

It’s a bit erratic as you can see. Some of this can be explained by the fact that I do in fact post in an erratic way while some of it is explained by the fact that some weeks only have a few days if they start on the 29th onwards.

Categories: Blogs

Exercise: Pair Programming Simulation using Tangrams

Agile Complexification Inverter - Fri, 07/10/2015 - 22:37
Yesterday (July, 2015) we did a lunch-n-learn at GameStop HQ on pair programming.  I think it was a great success, largely because we serve food, and I've been told that everything goes better when people are sharing a meal together (and even better with adult beverages).

Are you interested in Pair Programming?  I'll confess, the term is a bit misleading.  I was asked by multiple people if the topic was just for programmers.  No - no it's not just a programming technique. It is also for any kind of knowledge work.  Such as testing, or analysis, or writing stories, or ... yes coding, scripting, excel spreadsheets, etc.

The Agenda: Pair Programming Simulation
Start with a warm up exercise (totally non-related to the topic).  This allows all the late arrivals to find a seat and not miss out on the real start of the session.  I've found this technique (soft start) to be a required technique for companies that have not adopted basic meeting protocols, such as finishing prior to the start of the next meeting.  IF one does not finish on time, how can one start on time?

We used Thiagi's warm up of Buying Happiness

Flipped this lesson.  Although the experiment resulted in a - How Fascinating (failure).  No one actually participated in the homework to read the lesson before the experience session.  We continued without doing any actual lecture.

PDF - Pair Programming - Lessons

Query the audience - to share the common level of people with respect to the domain knowledge.  Ask a few questions - raise your hand if you have heard of pair programming, if you've done pair programming, if you only program in a pairs (every day)?  Look around - these are the experts.  Raise your hand if you are a beginner?  When you read the homework on pairing, you remember that pairing beginners with beginners is an anti-pattern.  So what shall we do about that?

Restructure the seating arrangements, have people select appropriate pair for their skill level.  Don't allow the beginners to sit together and the experts to create a click.

Part ONE.  Pair Drawing.Let's do the simplest thing that could possibly work... everyone has learned to draw/sketch.  Let's use this innate skill to explore pairing basics.

PDF - Pair Face Drawing
Part TWO.  Lunch.Typically what draws everyone to your meeting... food.  Don't do Lunch-n-Learn with out this.
Part Three.  Pair Puzzle Solving.Let's extend our learning into a harder problem domain... solving a puzzle - Tangrams.

PDF - Pair Puzzle - Tangram Solving

This exercise can touch upon the aspects of Test-First (TDD) practices.  Typically a topic for another Lunch-n-Learn.

Debrief.A great facilitator does the exercise / simulation just to get to the debrief.  Reflection is the only activity where double loop learning may occur.  Using metaphor and analogy to relate drawing faces or solving Tangrams to developing software is the job of the debrief.

In a large group with many subgroups this can be done by projecting the debrief question on the screen and having the subgroups (tables) debrief themselves.  Extra points given for summaries of learning points or action items discovered.
We did a debrief after each example problem.  Then ran out of time to debrief the whole workshop - but did get Level One feedback on the workshop.  It was a 8 or 9 (out of 10) with a few improvement to make for next time.

Categories: Blogs

Strategy Deployment as Organisational Improv

AvailAgility - Karl Scotland - Fri, 07/10/2015 - 16:14

IMG_0159At Agile Cymru this week Neil Mullarkey gave a superb keynote, introducing his rules of improv (left). He suggested that businesses can apply these rules to be more creative and collaborative, and that there is a lot of synergy with Agile. Like all the best keynotes, it got me thinking and making connections, in particular about how Strategy Deployment could be thought of as form of Organisational Improv.

I’ve blogged about Strategy Deployment a couple of times, in relation to the X-Matrix and Kanban Thinking, and Is Agile Working. Essentially it is a way for leaders to communicate their intent, so that employees are able decide how to execute. This seems just like an improv scene having a title (the intent), allowing the performers to decide how to play out the scene (the execution).

The title, and rules of the improve game, provide enabling constraints (as opposed to governing constraints) that allow many different possible outcomes to emerge. For example, we tried a game where in small groups of 4-5 people, we told a story, each adding one word at a time. The title was “The Day We Went To The Airport”. That gave us a “True North”, and the rules allowed a very creative story to emerge. Certainly something that no one person could have come up with individually!

B_SEWU8XIAIXsC5However, given our inexperience with improv, the story was extremely incoherent. I’m not sure we actually made to the airport by the time we had been sidetracked by the stewardesses, penguins and surfing giraffes (don’t ask). It was definitely skimming the edge of chaos, and I can’t help thinking some slightly tighter constraints could have helped. As an aside, I saw these Coyote/Roadrunner Rules recently (right). Adam Yuret pointed out that they were enabling constraints and I wonder if something like this would have helped with coherence?

What’s this got to do with Strategy Deployment? It occurred to me that good strategies provide the enabling constraints with which organisations improvise in collaborating and co-creating tactics to meet their True North. Clarity of strategy leads to improvisation of tactics, and if we take Neil’s Rules of Improv we can tweak them such that an offer is an idea for a tactic, giving:

  • Listen actively for ideas for tactics
  • Accept ideas for tactics
  • Give ideas for tactics in return
  • Explore assumptions (your own and others’)
  • Re-incorporate previous ideas for tactics
Categories: Blogs

New Video: Myths of Scrum – ScrumMaster Assigns Tasks

Learn more about our Scrum and Agile training sessions on

In a few weeks, I will be posting a more detailed written follow-up to this video.  This is one of the most damaging and most common myths (or pitfalls) that ScrumMasters fall into….

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!

The post New Video: Myths of Scrum – ScrumMaster Assigns Tasks appeared first on Agile Advice.

Categories: Blogs

SonarQube Swift Plugin Offers Mature Functionality for Young Language

Sonar - Fri, 07/10/2015 - 10:13

The Swift programming language is only a year old, but the SonarQube plugin for code written in this “green” language has already been out for six months and already offers a mature set of features.

The SonarQube Swift plugin is absolutely easy to use. All you need to do is specify the name of the project and the folder with the source files. As the analysis output, you get a wealth of metrics (lines of code, complexity etc.), code duplication detection, and of course, the most important and interesting thing: issues raised by your code.

The Swift language introduces a lot of new features, some of which developers have been waiting for for a long time (e.g. easy-to-use optional values), while others are a bit more controversial (operator overriding, custom operators). Love the new features or hate them, no developer is indifferent.

Because the Swift language is so new, our team has made an effort to create a pile of useful rules to help developers take proper advantage of its unique features. For instance, for those who are used to ending each switch case with a break, we have this rule: “break” should be the only statement in a “case”.
For those who are addicted to using custom operators, we have rules limiting the risks of using of this feature:

And for sure, the Swift plugin provides standard types of rules like name convention rules for all possible categories, a bunch of rules detecting too-complex code and other super useful bug detection rules such as:

The Swift language is developing rapidly, regularly releasing new versions with new features and syntax. At the recent WWDC 2015, Swift 2.0 was announced. It introduces error-handling mechanisms, defer statements, guard statements and a lot of other stuff. All of which is already supported by Swift plugin 1.4!

So if you are interested in being able to develop high quality Swift code quickly, take a look at Nemo to what the SonarQube Swift plugin offers, and then try it out for yourself.

Categories: Open Source

What Did You Miss? Real Stories, Insights, and Courage From RallyON Keynotes.

Rally Agile Blog - Thu, 07/09/2015 - 20:45

“Your goal is to get to the top of the mountain and you’re riding your bike, competing to get there first … and you get passed by a motorcycle. You’ve just experienced the type of disruption that many industries are experiencing.” — Angela Tucci, Rally chief revenue officer

Rally CTO and founder Ryan Martens, CEO Tim Miller, and CRO Angela Tucci welcomed us to  RallyON!™ 2015 by reminding us how disruption is game-changing — and how the pace of change is accelerating. Customer expectations, competitive shifts, and regulatory changes are all part of the disruption. So is the amount of information and all the different ways you can leverage it. Angela, Tim, and Ryan talked about how achieving organizational agility to deal with change of this magnitude requires architecting the whole business system for speed, steering, and opportunity.

This was our fifth annual RallyON conference. It’s grown from a Rally user event to a true conference on business agility, providing information, techniques, and examples about creating agility — not just in delivery teams, but throughout an entire organization.

Whether you missed the conference or just want a speed-read reminder of the inspiration and information from this year’s keynotes, read on. To take your next steps toward agility, access the RallyON presentations, and keep an eye out for even more great resources, including podcasts and videos (coming soon).

Create Agility By Disrupting Your Own Business

Every person in an Agile organization is a leader. And RallyON was all about giving business and technical leaders the inspiration, knowledge, and tools to create agility. So they can anticipate change by sensing market opportunities and responding more quickly and confidently than the competition — even if it means disrupting their own businesses.

“It’s sure more fun to disrupt than be disrupted. Someday a company’s going to come and put us out of business — so it might as well be us … this is the essence of agility.” — Josh Linkner

Josh Linkner, author of “The Road to Reinvention,” (@joshlinkner) helped kick off the conference by describing just that: “judo flips” designed to upend your operating model and disrupt your own business. He reminded the crowd that experimentation is an important part of the innovation process: “Try throwing your imagination at the problem, you may get a better result,” and “Mistakes are not failures, they are portals for discovery." He also got the whole crowd laughing by showing Louis CK’s interpretation of the 5 whys (here’s a similar clip) — usually an important technique in understanding innovation, root cause, and continuous process improvement.

One of our RallyON attendees, Kalpesh Shah, sketched out each of the keynotes. For Josh’s presentation, he captured this picture and the five myths that keep individuals (and our businesses) from innovating:

Design by: Kalpesh Shah, @AgileBrightSpot

Both Josh and Robert O’Neill, our closing keynote speaker for Monday, reminded us that everything takes practice, and that it’s not always easy.

“Training + communication + repetition = success. Training + communication + repetition = success. Training + communication + repetition = success.”

Creating agility in your business takes persistence and personal courage. We were honored to have Robert present and inspire us to trust our people and never give up.

“I'll never ask you to do anything impossible. I'm just going to ask you do do something very hard followed by something very hard. Just finish the next thing and you'll get there.” — Robert O'Neill

Trust and Courage

The crowd-favorite speaker (per the RallyON app voting) was Kirsten Wolberg (@KirstenWolberg), vice president of technology at PayPal (@PayPal). She kicked things off on Tuesday by talking about the courage required for a massive Agile undertaking at PayPal — one of the largest Agile transformations in the world involving more than 3,500 people.

She quickly captured the audience’s attention with:

  • How she adopted a big bang approach

  • Why incremental just wasn’t fast enough

  • Having just enough executive support

  • How she and her teams made it work with two (and only two) rules:
    1. Every team must have the same sprint cadence
    2. Every team must use the same software to make work visible

"I trust you, but think you will fail spectacularly." Captured in tweets by audience members: Kirsten quoting her boss, who provided enough executive support for the big bang approach.

Kirsten stressed the importance of practice and repetition: "We need to hear it 7 times and do it 21 times to create new learnings, new habits." To emphasize this, she shared that the KPIs PayPal used in year one were based solely on engagement. Not just on surveys but on actual information from software usage that measured real behavior. Later-year KPIs measured value delivery, because ...

“Who cares if you're getting stuff out the door faster if it's not meeting customer needs?” — Kirsten Wolberg, PayPal

Dan Pink (@DanielPink), author of “Drive,” reinforced messages from Kirsten, Josh, and Robert: Important information and innovation comes from trusted, empowered teams. Keeping up with the new pace of change requires a new management style and organizational structure that gives teams autonomy, mastery, and purpose. The research he shared provided insight into why embracing Agile culture is so important — and why adopting these practices at scale drives real business results like the ones at PayPal.

"If-then rewards: Great for resource efficiency, not so great for flow efficiency; great for rudimentary cognitive tasks, not so great for heuristic, complex work." — Daniel Pink

Dan also reminded us that feedback needs to change in 21st century operating systems. Annual employee reviews don’t even come close to cutting it. “The days that people feel most motivated are the days when they make progress on meaningful work. And that progress depends on feedback."

Going Big With Big Room Planning

RallyON Wednesday kicked off with a Rally solutions session — how Rally products and services help our customers deliver business results. Shannah Van Winkle, corporate initiative owner, shared Rally’s proven Ready-Sync-Go process that helps businesses adopt Agile methodologies at enterprise scale and deliver higher-quality products, faster.

Ryan Polk, Rally vice president of product, and Steve Demchuk, Rally chief product owner talked about the benefits of big room planning — and Rally’s new and unique software support for this important event.

“Our expert transformation consultants have helped with over 200 big room planning sessions over the last 2 years alone. These are 200 planning sessions where delivery groups raised risks, identified dependencies, and planned the most critical and important work to do next.” — Shannah Van Winkle

Another Big Bang, Enterprise Scale Agile Success Story

RallyON was lucky to have another fantastic customer keynote on Wednesday. Joan Bohannon and Thomas Hall of Physicians Mutual shared their Agile transformation journey, from making the decision to change all the way through working to create agility in their portfolio.

Like PayPal, Physicians Mutual took a big bang approach that delivered real business results.

Joan shared that Physicians Mutual originally intended to pilot two teams using Rally's Agile software platform and consulting services. But when initial teams got started, other teams got excited and wanted to jump in as soon as possible. With this kind of pull, Physicians Mutual realized that a big bang approach was probably the way to go. They launched 14 teams with 250 people and in just a few months, went from 4 to 6 major releases annually, with minor releases at the end of each 3-week iteration — all while delivering higher quality and more customer value.

Audience members also rated this presentation as one of their favorites, via tweets and RallyON app updates such as, “Joan’s delivery is fantastic. Her humor and honesty, along with the details of how this worked, all deliver a powerful impact.”

Back to Our Roots

For the final RallyON keynote, we returned to our roots and purpose. At Rally, we dedicated founding stock to our community to create the Rally For Impact Foundation and for a partnership with Code for America. We were proud to have a civic-tech track where Hillary Hartley (@hillary), deputy executive director at 18F, talked about how you can bring agility to places you might not have ever imagined possible — like our federal government.

The Right Next Step

In many of the keynotes, presenters asked, “What are you doing to change today? What’s the right next step for you (in creating more agility in your business)?” I hope you found the information and inspiration at RallyON to answer these questions, and that you’re already taking the right next step for you and your organization.

We hope to see you next at Agile 2015, at CA World, and beyond.


Christine Hudson
Categories: Companies

An Agile Team Task by Any Other Name – A To Do

Agile Management Blog - VersionOne - Thu, 07/09/2015 - 14:30

Sprint Planning HellLet me first say, I know the idea of task decomposition is fairly well covered and some might call it a basic practice of any team; however, as a coach helping teams to adopt agile software development, I don’t always see teams finding this practice of defining “how to get to done” as a natural team planning activity. Instead, I see teams getting frustrated with a clunky approach or a high-level of disengaged team members or a member of the process police controlling the meeting that is distinctly a team meeting or I still see the “lead” define the tasks and simply dole them out.

Defining “How” to get stuff done as a team should be the straightforward activity around software development. It should be an engaging activity of brainstorming, learning, sometimes arguing, and ultimately a good feeling of “let’s git’r done.” All-too-often it seems like a torture technique riddled with challenges. These challenges are often rooted simply in poor practices, some of which include:

  • Creating faux work breakdown structures (yes, I said it — WBS) of standard tasks (e.g. each story has “Design”, “Code”, “Review”, “Test”, “Deploy” tasks). Some would argue this is not a poor practice, but tasks should have context and be relative. Not to mention, this is kind of mundane, requires no thought, and is flat out lazy and contrived.
  • Focusing on the accuracy of hour level estimation. If we are consistent with relative estimation and looking at cycle time, we can come up with the “low risk” and lean approach to determine which stories to work on. Estimation at this level is more of a measure of certainty.
  • Creating tasks and tests that are ginormous — like a 40 hour task for a two week iteration. If someone tells me that it’s going to take 40 hours, then I view that as high risk and we need to keep talking about it to better understand it.
  • On the other hand, creating micro tasks — yes, so many that the Task board looks like a sticky note factory exploded on the wall or invoke pagination within the tool.
  • Having the developer and tester creating tasks and tests in isolation without any conversation with each other or the rest of the team.
  • Oh yeah, let’s not forget when I get asked about reports that measure how underutilized people might be. Often the focus of understanding “How” becomes simply an exercise to maximize utilization.

That last point about utilization, it seems like a frequent driver of the planning exercise. It’s odd in that sometimes people think that if we don’t have a plan with everything defined that we are going to do before we go do it; well — when the stuff we do get done is complete, we’ll simply stop working and sit there and stare at each other. I’m pretty sure that this is never the case and if it is, either get new people or look in the mirror.

Does any of this sound familiar? Does any of this frustrate you?

Well, I have a few ideas for you to try — most of these are common sense and talked about by others, but it’s always good to mix it up and try something different to get out of the rut or remove the pain associated with planning.

First, abandon planning using ideal hours — I know, I’m crazy — but hear me out. The common rule for any to do or task is that it should take no more than a day to get completed, ideally less. Tobias Mayer’s book called The People’s Scrum contains a curated set of his past blog posts, one in particular called, “When is Scrum not Scrum?” explains his reasoning for non-estimated, day or less tasks — (1) eases tracking – just burndown tasks — the burndown is number of remaining open tasks and (2) it helps to unearth unforeseen impediments that are often just part of what we normally do. While these are great, I would add that focusing on estimates and accuracy of the estimates actually just results in taking the eye off quality and flow of value.

SPECIAL NOTE – If you are a VersionOne user and worried about not getting a burndown, try using just a “1” in for the Detailed Estimate and To Do.  This will, in essence, create a task count burndown.

Next, decompose just enough stories to commit to the goal and get started. The Scrum Guide is pretty clear about this:

… enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting.

Now, new teams may need to decompose all stories during a sprint planning, but teams that have been together for a while may be able to quickly determine what stories to do in the next two weeks, how they fit an incremental goal, and then just go. Don’t make your sprint planning meetings more painful — if you are planning for 2 hours and you have enough work to start the sprint, then go start.

Try different techniques for this meeting that encourage engagement. For example:

Taskstorming. A simple approach where the team selects which stories they are going to work on based on past velocity and then, interviews the Product Owner on each. During the interview, the teams is noting on sticky notes the tests and tasks. Once a goal emerges, then it’s time to task [and test] storm. On a whiteboard, write the title and draw a large box for each story. Now have the team place their sticky notes up on each story. Duplicates can be discussed as well as someone can put up something that doesn’t make sense to anyone else — well discuss it. Through this process, let the conversations flow – observe a story with a ton of task, then maybe it should be broken apart? Taskstorming not only makes the meeting more efficient, but it’ll make it more effective because everyone is involved and engaged in the process. At the end, have folks pair up and help get the data captured in your favorite tool (which means VersionOne).

Other techniques you can try include Task-n-Tell and Test First Tasking.

Finally, as I’ve mentioned in a couple past blogs, put this on the team – this is a team activity. If you are a team member, take ownership of this meeting and you lead it. The Scrum Master or Lead or Facilitator of the team would typically do this, but if you find them directing or assigning tasks out without engagement. Well you have a problem and the best way to change it is for a team member to take over. If you are a Scrum Master or Lead and you are struggling with getting the team engaged, try something new — don’t be insane. Try introducing a facilitation game or asking someone else to facilitate (not the product owner or anyone else in a position of authority).

No one should suffer through a sprint planning meeting. Yes they can be hard, but they shouldn’t be torture — so, inspect and adapt. Time to make them fun and effective.

Remember that at the end of the day, tasking is simply defining the proverbial “To Do” list to get a story done.

Categories: Companies

Our web life in 2014

Growing Agile - Thu, 07/09/2015 - 14:19
At the start of 2014 we looked at how our website was d […]
Categories: Companies

R: dplyr – Error: cannot modify grouping variable

Mark Needham - Thu, 07/09/2015 - 07:55

I’ve been doing some exploration of the posts made on this blog and I thought I’d start with answering a simple question – on which dates did I write the most posts?

I started with a data frame containing each post and the date it was published:

> library(dplyr)
> df %>% sample_n(5)
                                                title                date
1148 Taiichi Ohno's Workplace Management: Book Review 2008-12-08 14:14:48
158     Rails: Faking a delete method with 'form_for' 2010-09-20 18:52:15
331           Retrospectives: The 4 L's Retrospective 2011-07-25 21:00:30
1035       msbuild - Use OutputPath instead of OutDir 2008-08-14 18:54:03
1181                The danger of commenting out code 2009-01-17 06:02:33

To find the most popular days for blog posts we can write the following aggregation function:

> df %>% mutate(day = as.Date(date)) %>% count(day) %>% arrange(desc(n))
Source: local data frame [1,140 x 2]
          day n
1  2012-12-31 6
2  2014-05-31 6
3  2008-08-08 5
4  2013-01-27 5
5  2009-08-24 4
6  2012-06-24 4
7  2012-09-30 4
8  2012-10-27 4
9  2012-11-24 4
10 2013-02-28 4

So we can see a couple of days with 6 posts, a couple with 5 posts, a few more with 4 posts and then presumably loads of days with 1 post.

I thought it’d be cool if we could blog a histogram which had on the x axis the number of posts and on the y axis how many days that number of posts occurred e.g. for an x value of 6 (posts) we’d have a y value of 2 (occurrences).

My initial attempt was this:

> df %>% mutate(day = as.Date(date)) %>% count(day) %>% count(n)
Error: cannot modify grouping variable

Unfortunately that isn’t allowed. I tried ungrouping and then counting again:

 df %>% mutate(day = as.Date(date)) %>% count(day) %>% ungroup() %>% count(n)
Error: cannot modify grouping variable

Still no luck. I did a bit of googlign around and came across a post which suggested using a combination of group_by + mutate or group_by + summarize.

I tried the mutate approach first:

> df %>% mutate(day = as.Date(date)) %>% 
+     group_by(day) %>% mutate(n = n()) %>% ungroup() %>% sample_n(5)
                                                        title                Source: local data frame [5 x 4]
                                    title                date        day n
1 QCon London 2009: DDD & BDD - Dan North 2009-03-13 15:28:04 2009-03-13 2
2        Onboarding: Sketch the landscape 2013-02-15 07:36:06 2013-02-15 1
3                           Ego Depletion 2013-06-04 23:16:29 2013-06-04 1
4                 Clean Code: Book Review 2008-09-15 09:52:33 2008-09-15 1
5            Dreyfus Model: More thoughts 2009-08-10 10:36:51 2009-08-10 1

That keeps around the ‘title’ which is a bit annoying. We can get rid of it using a distinct on ‘day’ if we want and if we also implement the second part of the function we end up with the following:

> df %>% mutate(day = as.Date(date)) %>% 
    group_by(day) %>% mutate(n = n()) %>% distinct(day) %>% ungroup() %>% 
    group_by(n) %>%
    mutate(c = n()) %>%
Source: local data frame [6 x 5]
Groups: n
                                                title                date        day n   c
1       Functional C#: Writing a 'partition' function 2010-02-01 23:34:02 2010-02-01 1 852
2                            Willed vs Forced designs 2010-02-08 22:48:05 2010-02-08 2 235
3                            TDD: Testing collections 2010-07-28 06:05:25 2010-07-28 3  41
4  Creating a Samba share between Ubuntu and Mac OS X 2012-06-24 00:40:35 2012-06-24 4   8
5            Gamification and Software: Some thoughts 2012-12-31 10:57:19 2012-12-31 6   2
6 Python/numpy: Selecting specific column in 2D array 2013-01-27 02:10:10 2013-01-27 5   2

Annoyingly we’ve still got the ‘title’, ‘date’ and ‘day’ columns hanging around which we’d need to get rid of with a call to ‘select’. The code also feels quite icky, especially the use of distinct in a couple of places.

In fact we can simplify the code if we use summarize instead of mutate:

> df %>% mutate(day = as.Date(date)) %>% 
    group_by(day) %>% summarize(n = n()) %>% ungroup() %>% 
    group_by(n) %>% summarize(c = n())
Source: local data frame [6 x 2]
  n   c
1 1 852
2 2 235
3 3  41
4 4   8
5 5   2
6 6   2

And we’ve got also rid of the extra columns in the bargain which is great! And now we can plot our histogram:

> library(ggplot2)
> post_frequencies = df %>% mutate(day = as.Date(date)) %>% 
    group_by(day) %>% summarize(n = n()) %>% ungroup() %>% 
    group_by(n) %>% summarize(c = n())
> ggplot(aes(x = n, y = c), data = post_frequencies) + geom_bar(stat = "identity")

2015 07 09 06 44 47

In this case we don’t actually need to do the second grouping to create the bar chart since ggplot will do it for us if we feed it the following data:

. ggplot(aes(x = n), 
         data = df %>% mutate(day = as.Date(date)) %>% group_by(day) %>% summarize(n = n()) %>% ungroup()) +
    geom_bar(binwidth = 1) +
    scale_x_continuous(limits=c(1, 6))
2015 07 09 06 55 12

Still, it’s good to know how!

Categories: Blogs

Driving Self-Organization

Agile Tools - Thu, 07/09/2015 - 05:46

Bangalore Traffic

“Too bad the only people who know how to run the country are busy driving cabs and cutting hair.”

-George Burns

I learned to drive in Southern California. I’ve always been kind of proud of that fact. Driving in the southern land of pavement and potholes requires a special kind of aggressive driving in order to survive the freeway melee. You have to learn to barge into a lane when there isn’t any room, to turn left on a light after it turns red, to tailgate in order to keep others from cutting you off. That’s quite a litany of questionable driving practices. All in a typical day of driving in Cali. Don’t mess with me, I’m an expert.

That’s what I thought before I went to India.

Driving in a taxi in India was an eye opening experience. Silly little conventions like lanes are completely ignored. The entire road, from sidewalk to sidewalk, is your vehicular playground. Driving the wrong way into oncoming traffic is a matter of habit – how else would you get where you are going? I tried to count the number of times I was nearly in a head on collision, but I gave up – partly because I lost count, and (maybe) because I was distracted by my own screaming.

Don’t get me wrong: I was in complete and utter admiration. The level of self-organization and complexity was breathtaking! With what appeared to be a complete absence of rules, people managed to get to and from work every day amidst what appeared to be complete chaos. I very quickly resolved to never lecture anyone on the merits of self-organization ever again! Why? Because apparently I’m an amateur. If you want a lesson in professional level self-organization, don’t talk to me. Talk to a taxi driver in Bangalore.

Someone asked me if I thought I could drive in that traffic. My answer was yes, but not because I think I’m good. Quite the opposite in fact. The Indian driving system appeared to be remarkably tolerant of incompetence. The traffic ebbed and flowed around complete bumbling dolts with apparent ease. Contrast that with where I live in Seattle: one idiot in the left lane can shut down an entire freeway for hours.

Each day in India, I took a one hour commute to and from the office through complete chaos. We circumvented obstacles that would have shut down a US freeway for hours. The creativity on display was dazzling. And as an added bonus, I was thankful to be alive when I arrived at my destination!

Compare that to my commute in the US. Everyone lines up uniformly. We stay in our lanes. Creativity is discouraged. It’s not very exciting. My commute at home also takes an hour. It made me wonder: which system is more efficient?

Under what conditions is a system with fewer rules faster than a system with relatively rigid rules? It was tempting to look at the Bangalore traffic and speculate that perhaps it was faster in some ways. It was certainly more exciting (especially after a few beers late at night in an auto-rickshaw). However, a certain level of orderliness also has its benefits.

I find myself on my own humble commute now, cars stacked up in nice, orderly lines behind an endless parade of red tail lights – and I wonder, “What if we had fewer rules?”

Filed under: Agile, Swarming Tagged: Agile, driving, performance, self-organization
Categories: Blogs

July Job Seeker Discounts for CSM and CSPO Workshops

Agile Learning Labs - Thu, 07/09/2015 - 01:38

When you are between jobs, you have a golden opportunity to invest in your own professional development. Agile Learning Labs wants you to take advantage of this opportunity to invest in yourself, so we are making spots in our July Certified Scrum Master (CSM) and Certified Scrum Product Owner (CSPO) workshops available to job seekers for half price. This is a one-time offer for July only.

Are you a job seeker and ready to take us up on our offer? Here are links you can use to register for our July workshops:

Certified Scrum Master Workshop July 21 & 22

Certified Scrum Product Owner Workshop July 23 & 24



Categories: Companies

A commitment is not a guarantee

Pivotal Tracker Blog - Wed, 07/08/2015 - 21:38

If your team uses Scrum as a development process, the team decides which of the next most important items it can complete by the end of the iteration. However, this “commitment” is often used to hold the team accountable for the amount of work that will be shipped by the end of the sprint. Holding your team accountable for failing to deliver on their engagements is counterproductive and will act as a regime of terror. This is no small issue, and Scrum now suggests using the word forecast instead of commitment.

How can commitments be abused?
Commitments can be abused by management as a way of holding the team accountable. Typically, the manager or even stakeholders will say that they made engagements (i.e., announced a detailed release) based on what the team said they could deliver. They usually fix this situation by asking the team to work overtime in order to deliver on their own promises.

Yes, the goal is to burn down until you reach 0, but not at any price. If developers fear that they won’t make it by the end of this iteration and you made it clear that they promised to finish, you are basically forcing them to cut down on quality.

Overtime is borrowed time and it has an interest rate
Every time you make a deadline because your team worked overtime, don’t be too quick to celebrate. The work they did on overtime may very well be of lower quality. After all, they were not as fresh-minded as they should’ve been.

Making your team work overtime is paying your debts with their health and the quality of your product. Those two things also happen to be the main things actually delivering value and making money to your company.

After a rush, the normal reaction will be to sit back and relax. If you want your process, your work output, and your project to be predictable, this is the last thing you want. Your team’s velocity will be inconsistent from one iteration to the next and inconsistent velocity leads to unpredictability.

blame_game_smallThe blame game has no winners
No matter the problem, when the discussion is aimed at finding a person to blame, it’s better to not even have that discussion. Instead of trying to find the who, we should always be focused on the why we want to objectively find solutions.

If management uses those engagements in order to blame the team—or worse, a specific person—not only does it nurture fear for their next iteration planning, but it also fails to solve the real problem(s).

Either way, whether the commitment concept is abused by management or by the developers themselves, the usual victim is product quality, as Ken Schwaber himself has repeatedly pointed out.

What should you hold your team accountable for?
The team is responsible for building great software—that’s it. It’s the only thing the team is responsible for and it’s the only thing that they actually control. In other words, the development team is committed to quality software.

The commitment aspect of iterations is just there to focus the team on the next most important set of functionalities. Holding them accountable on their shortcomings is leading by fear.

In the end, a manager who abuses his team’s engagements against it is inadvertently lowering the quality standards of the product as whole.

Yes, it’s fine to deliver on time, but not at all costs.

Contributor: Emanuel Petre

Emanuel is the cofounder of Insight, an Agile dashboard for Pivotal Tracker.

He is an engineer with a passion for technology and innovation in general. Outside of work, you can find him spending time with his girlfriend and kids. He also enjoys swimming and reading.

The post A commitment is not a guarantee appeared first on Pivotal Tracker.

Categories: Companies

Entity Framework extensions for AutoMapper

Jimmy Bogard - Wed, 07/08/2015 - 16:12

I pushed out a little library I’ve been using for the last couple years for helping to use AutoMapper and Entity Framework together. It’s a series of extension methods that cuts down the number of calls going from a DbSet to DTOs. Instead of this:

Mapper.CreateMap<Employee, EmployeeDto>()
  .ForMember(d => d.FullName, opt => opt.MapFrom(src => src.FirstName + " " + src.LastName));

var employees = await db.Employees.ProjectTo<EmployeeDto>().ToListAsync();

You do this:

public class Employee {
  public string FullName { get { return FirstName + " " + LastName; } }
Mapper.CreateMap<Employee, EmployeeDto>();

var employees = await db.Employees.ProjectToListAsync<EmployeeDto>();

The extension methods themselves are not that exciting, it’s just code I’ve been copying from project to project:

public static async Task<List<TDestination>>
  ProjectToListAsync<TDestination>(this IQueryable queryable)
  return await queryable

I have helper methods for:

  • ToList
  • ToArray
  • ToSingle
  • ToSingleOrDefault
  • ToFirst
  • ToFirstOrDefault

As well as all their async versions. You can find it on GitHub:

And on NuGet:


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

Categories: Blogs

Pitfall of Scrum: Focus on Scrum Tools

Learn more about our Scrum and Agile training sessions on

Many organizations try to find an electronic tool to help them manage the Scrum Process… before they even know how to do Scrum well! Use team rooms and manual and paper-based tracking for early Scrum use since it is easiest to get started. Finding a Scrum tool is usually just an obstacle to getting started.

The culture of most technology companies is to solve problems with technology. Sometimes this is good. However, it can go way overboard. Two large organizations have attempted to “go Agile” but at the same time have also attempted to “go remote”: to have everyone using electronic Scrum tools from home to work “together”. The problem with electronic Scrum tools is three-fold. They

  1. prevent the sharing of information and knowledge,
  2. reduce the fidelity of information and knowledge shared, and
  3. delay the transfer of information and knowledge.
Scrum Tools Prevent Information Sharing

Imagine you are sitting at your desk in a cubicle in an office. You have a question. It’s a simple question and you know who probably has the answer, but you also know that you can probably get away without knowing the answer. It’s non-critical. So, you think about searching the company directory for the person’s phone number and calling them up. Then you imagine having to leave a voice mail. And then you decide not to bother.

The tools have created a barrier to communicating. Information and knowledge are not shared.

Now imagine that the person who has the answer is sitting literally right next to you. You don’t have to bother with looking up their number nor actually using a phone to call. Instead, you simply speak up in a pretty normal tone of voice and ask your question. You might not even turn to look at them. And they answer.

Scrum tools are no different from these other examples of tools.  It takes much more energy and hassle to update an electronic tool with relevant, concise information… particularly if you aren’t good with writing text.  Even the very best Scrum tools should only be used for certain limited contexts.

As the Agile Manifesto says: “The most effective means of conveying information to and within a team is face-to-face communication.”

Scrum Tools Reduce Information Fidelity

How many times have you experienced this? You send an email and the recipient completely misunderstands you or takes it the wrong way. You are on a conference call and everyone leaves the call with a completely different concept of what the conversation was about. You read some documentation and discover that the documentation is out of date or downright incorrect. You are using video conferencing and its impossible to have an important side conversation with someone so you resort to trying to send text messages which don’t arrive on time to be relevant. You put a transcript of a phone call in your backlog tracking tool but you make a typo that changes the meaning.

The tools have reduced the fidelity of the communication. Information and knowledge are incorrect or limited.

Again, think about the difference between using all these tools and what the same scenarios would be like if you were sitting right beside the right people.  If you use Scrum tools such as Jira, Rally* or any of the others, you will have experienced this problem.  The information that gets forced into the tools is a sad shadow of the full information that could or should be shared.

As the Agile Manifesto says: “we have come to value: individuals and interactions over processes and tools.”

Scrum Tools Delay Information Transfer

Even if a person uses a tool and even if it is at the right level of fidelity for the information or knowledge to be communicated, it is still common that electronic tools delay the transfer of that information. This is obvious in the case of asynchronous tools such as email, text messages, voice mail, document repositories, content management systems, and version control. The delay in transfer is sometimes acceptable, but often it causes problems. Suppose you take the transcript of a conversation with a user and add it into your backlog tracking tool as a note. The Scrum Team works on the backlog item but fails to see the note until after they have gone in the wrong direction. You assumed they would see it (you put it in there), but they assumed that you would tell them more directly about anything important. Whoops. Now the team has to go back and change a bunch of stuff.

The Scrum tools have delayed the communication. Information and knowledge are being passed along, but not in a timely manner.

For the third time, think about how these delays would be avoided if everyone was in a room together having those direct, timely conversations.

As the Agile Manifesto says: “Business people and developers must work together daily throughout the project.”

Alternatives to Scrum Tools

Working in a team room with all the members of the Scrum Team present is the most effective means of improving communication. There are many photos available of good team rooms. To maximize communication, have everyone facing each other boardroom-style. Provide spacious walls and large whiteboards. Close the room off from other people in the organization. Provide natural light to keep people happy. And make sure that everyone in the room is working on the same thing! Using Scrum tools to replace a team room is a common Scrum pitfall.

Scrum Tools - Labelled Team Room Photo

The most common approach to helping a team track and report its work is to use a physical “Kanban” board. This is usually done on a wall in which space is divided into columns representing (at least) the steps of “to do”, “in progress” and “done”. On the board, all the work is represented as note cards each with a separate piece of work. The note cards are moved by the people who do the work. The board therefore represents the current state of all the work in an easy-to-interpret visual way. Using a tool to replace a task board is another variant of this common Scrum pitfall.

This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.

* Disclaimer: BERTEIG is a partner with a tool vendor: Version One.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!

The post Pitfall of Scrum: Focus on Scrum Tools appeared first on Agile Advice.

Categories: Blogs

GitHub pull request analysis helps fix the leak

Sonar - Wed, 07/08/2015 - 12:15

If you follow SonarSource, you are probably aware of a simple and yet powerful paradigm that we’re using internally: the water leak concept. That is how we’ve been working on a daily basis at SonarSource since a couple of years already, using various features of SonarQube like “New Issues” notifications“Since previous version” differential period, and quality gates. These features allows us to make sure that no technical debt is introduced on new code. More recently, we have developed a brand new plugin to go even further in this direction: the SonarQube GitHub Plugin.

Analysing GitHub pull requests to detect new issues

At SonarSource, we use GitHub to manage our codebase. Every bug fix, improvement, and new feature is developed in a Git branch and managed through a pull request on GitHub. Each pull request must be reviewed by someone else on the team before it can be merged into the master branch. Previously, it was only after the merge and the next analysis (every master branch is analysed on our internal SonarQube instance several times a day) that SonarQube feedback was available, possibly leading to another pull request-review cycle. “Wouldn’t it be great” we thought, “if the pull request could be reviewed not only by a teammate, but also by SonarQube itself before being merged?” That way, developers would have the opportunity to fix potential issues before they could be injected into the master branch (and reported on the SonarQube server).

This is what we achieved with the new SonarQube GitHub Plugin. Basically, every time a pull request is submitted by a member of team, the continuous integration system launches a SonarQube preview analysis with the parameters to activate the GitHub plugin, so that:

  1. When the SonarQube analysis starts, the GitHub plugin updates the status of the pull request to mention that there’s a pending analysis
  2. Then SonarQube executes all the required language plugins
  3. And at the end, the GitHub plugin:
    • adds an inline comment for each new issue,
    • adds a global comment with a summary of the analysis,
    • and updates the status of the pull request, setting it to “failed” if at least one new critical or blocker issue was found.

Here’s what such a pull request looks like (click to enlarge):

Pull Request Analysis with SonarQube GitHub Plugin

Thanks to the GitHub plugin, developers get quick feedback as a natural, integrated part of their normal workflow. When a GitHub analysis shows new issues, developers can choose to fix the issues and push a new commit – thus launching a new SonarQube analysis. But in the end, it is up to the developer whether or not to merge the branch into the master, whatever the status of the pull request after the analysis. The SonarQube GitHub plugin provides feedback, but the power remains where it belongs – in the hands of the developers.

What’s next?

Now that the integration with GitHub has proven to be really useful, we feel that doing a similar plugin for Atlassian Stash would be valuable, and writing it should be quite straightforward.

Also, analysing pull requests on GitHub is a great step forward, because it gives early feedback on incoming technical debt. But obviously, developers would like to have this feedback even earlier: in their IDEs. This is why in the upcoming months, we will actively work on the Eclipse and IntelliJ plugins to make sure they allow developers to efficiently fix issues before commit and adopt the “water leak” approach wholesale. To achieve this target, we’ll update the plugins to run SonarQube analyses in the blink of an eye for instantaneous feedback on the code you are developing.


Categories: Open Source

You Can’t Break it Down Until You Understand it

Agile Tools - Wed, 07/08/2015 - 06:01


“Furious activity is no substitute for understanding”

– H. H. Williams

One of the first things that agile or iterative development demands of us is that we should break down our work into very small chunks. This challenge is one of the first hurdles faced by teams that are adopting sprints and trying to make all of their work fit into a tiny little 2 week time box. I’ve seen it over and over again. The first question folks ask is, “How can I break this down into pieces small enough to fit in the sprint?” My response, inadequate though it may be, is some variation on, “It’s not hard. People do it every day.” I know – not the best answer. I often get reactions that range anywhere from frank denial to outright disbelief. It just can’t be done!

I know. I get it. I really get it. If you aren’t used to it, the first time you deal with breaking work down into tiny chunks is like running into a cognitive wall. I remember the first iterative project that I did. I understood the model. The concepts made sense: break things down into small chunks and then iterate. Easy.

Only it wasn’t easy at all.

I remember sitting in front of my monitor thinking, “What meaningful piece of functionality could we do in a sprint?”

Nothing came to mind. I drew a total blank.

It was dreadful. We were working on a new product, something completely new to the market…and I had no idea what I was doing. We had no clue. That’s not to say that we were incompetent. Far from it. We all knew that we didn’t know much, and that was a big problem. Fortunately, we overcame those challenges. Unfortunately, like many people, I conveniently forgot most of those lessons and moved on.

I had another reminder the other day. I was working on the boat I’ve been building. So much of building a boat early on was big intimidating chunks of work. I had no idea what I was getting into. Everything seemed daunting. Weeks of effort. However, after 3 years of working on it in my garage, I now find myself doing something completely different. Now I can wander out and create a long list of tiny tasks quickly and spontaneously. I know much more now. I can see hundreds of little tasks that need to be done. Little stuff, literally just a few minutes of work.

So I didn’t know what I was doing when I started, but I learned, and as I learned I was able to break things down. So how did I learn? By getting started and making mistakes. Lots of mistakes. Sometimes I think mistakes are the only thing I’m good at. So now when people ask how to break things down, maybe my answer is, “Just get started, the answer will come to you as you learn the problem domain.”

Of course, if that fails, you can always take up boat building.
Filed under: Uncategorized
Categories: Blogs

So Different…Yet Very Much the Same

Illustrated Agile - Len Lagestee - Tue, 07/07/2015 - 22:40

I’m writing this in near total darkness during a planned power outage (called load shedding) in a time zone 7 hours ahead of my home in Chicago. Hang on battery…hang on!

It’s been almost 8 weeks since I landed abroad to start an Agile coaching assignment. Admittedly, I was nervous. Would I be able to make a difference? Would I be able to resonate with the people here? How different could things really be?

Well…things are different. From driving on the left hand side of the road (just a couple of near misses) to the dry weather as the country moves from fall into winter (just a few drops of rain since I’ve been here) there is much for a foreigner to get accustomed to.

During this time abroad, I have learned a bit about different but popular sports here including rugby and cricket. On my first day, when someone said to “Put on your scrum cap and gum guard!” I knew this was going to be an adventure right from the start. And I think I almost have the scoring for cricket figured out. Innings…both singular and plural. Interesting.

I am also learning more about the history and complexities of this stunningly beautiful country. The people here are dealing with significant and daunting issues touching the sensitive core of their culture. While I will never be able to empathize with their struggles, I’ve heard stories of how demoralized some people are. They have come a long way since 1994 but it’s clear there is more work to do. Not throwing stones as we are clearly a work in progress ourselves.

Even though there are differences, I have discovered an overwhelming sense of just how much we have in common. On most days it feels like I’m just a few blocks from home instead of 9,000 miles away. Everyone I have met has been warm and welcoming and I’m sure I’ve connected with people who will become lasting friends.

From an organizational transformation perspective, it seems no matter where one is in the world, everyone is being challenged with many of the same things.

People are consistently under pressure. Because there is a focus is on “results at all cost”, people are overwhelmed and under tremendous stress. The number of people who have shared this sentiment with me from both continents are staggering. Many are dealing with physical ailments directly related to stress and overwork from their work environment.

Organizations are carrying a tremendous amount of process baggage. The volume of complex systems and defensive processes are heavy and burdensome, weighing down the best of intentions for improvement. There seems to be an unwillingness to let go of old paradigms and keeping meaningful and lasting change completely out of reach. Systems and processes are not aligned with the needs of people, putting even more pressure on them.

There is a real struggle to transform organizations attempting to thrive in an increasingly fast-paced and ever-changing world. Just overlaying or implementing “Agile” into a culture unwilling to address core, systemic issues will cause any attempt at agility to become just another failed change initiative.

As part of my work, my passion is to become a catalyst for change within these organizations crying out for greater agility. In some small way, I hope to guide companies to find the balance between delivering results while fostering a culture which embraces and appreciates what most leaders would claim is their most valuable “resource”, people.

Are you attempting to be a catalyst for change in your organization? Are you feeling overwhelmed and unsure where to start? Are you hitting brick wall after brick wall? Are people just “not getting it?” Remember, change is messy and never a straight line. You are not alone. Reach out to other catalysts around the world. Then start with one person, one team, and one leader at a time.

More to come…

Becoming a Catalyst - Scrum Master Edition

The post So Different…Yet Very Much the Same appeared first on Illustrated Agile.

Categories: Blogs

AutoMapper dev builds moved to MyGet

Jimmy Bogard - Tue, 07/07/2015 - 20:08

I’m moving the dev builds for AutoMapper to MyGet, here:

I’ll still have pre-release builds on NuGet, but it’ll be a little less noisy having the NuGet builds be only builds from master.



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

Categories: Blogs

Portfolio Management – Idle Teams

Notes from a Tool User - Mark Levison - Tue, 07/07/2015 - 15:49

Portfolio Management

(Continued from Portfolio Management Part 1 in the Scrum Alone is Not Enough series.)

Imagine that the Portfolio Management group is giving the individual Product Owners a budgetary envelope of an approximate size. As Product Owners, we expect to make small bets on individual User Stories that will deliver value to the customer. The Portfolio Management group wants to make mid-sized bets (>1 Team Sprint) that will deliver value to the customer.

But let’s say the current Sprint is one in which some Team members don’t really have a lot to do. This is the type of scenario that often drives management crazy because they see idle workers, and traditional thinking is that idle workers don’t deliver value. This rarely ever happens in real life because there’s almost always more work than there is Teams to do it, but should the rare situation occur when one doesn’t have work in the current Sprint, questions that arise may be things like:

  • should we temporarily reassign those Team members to other teams/projects that are lagging behind, to help them catch up?
  • should we give them a feature that is further down the road in the backlog to work on in the meantime, with the thinking that it will give us a head start on it since they’re sitting idle anyway?

The answer is, of course, to do neither.

If the ‘idle’ Team were to join another Team temporarily, it wouldn’t speed things up – just the opposite, it would slow everything down. Disrupting that Team’s effectiveness and cadence, their contribution would be much smaller than their effect in reducing the other Team’s capacity. In addition, it could harm moral by suggesting that the other Team can’t handle the tasks themselves.

And if the idle workers start developing a Feature that is further ahead on the Backlog, it undermines the Product Owner and Portfolio Management’s priority settings and decisions, which leaves room for “hey, could you do me a quick favour” requests within the Sprint that weren’t in the Sprint backlog. By the time the rest of the Team gets to that feature in the backlog, they may find that the work the idle Team had made on it is obsolete and needs to be undone before they can make new progress.

The best solution is have ‘idle’ Team members look at the board and see if there are bottlenecks that they can help with within their own Team. They could also pay down their technical debt, or spend time learning something that expands their capacity as a Team to work outside of their current area/column(s) on the Kanban chart. For example, the Team in the previous examples might teach themselves something about testing or creating effective online help.

The most effective thing (in terms of delivering value) is to not focus on the idle worker at all, but continue to focus on finishing the work and maximizing value delivered to the customer. This is where Portfolio Management can really excel, by understanding this fundamental truth and facilitating it.


Categories: Blogs

Link: About Development Managers

Learn more about our Scrum and Agile training sessions on

My colleague and friend Mike Caspar has posted another insightful article on his blog: Do not create unnecessary fear and animosity with Development Managers.  From the article:

As teams grow, they build confidence and seem to become self-contained, and almost insular to some. This is normal and is not a sign of dysfunction. This simply indicates that the team is starting to have self identity. They are starting to act as a team. This is a good sign…. As the teams become more effective, the Development Manager feels more loss.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!

The post Link: About Development Managers appeared first on Agile Advice.

Categories: Blogs

Knowledge Sharing

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