Skip to content

Feed aggregator

Reflecting on the Intentional Routine

Evolving Excellence - Sun, 12/14/2014 - 05:35

vonnegutMy post a couple weeks ago on Gratitude, for Gratitude, generated a large number of responses.  Interestingly, most were private, commenting on both the nature of gratitude but especially on my daily routine.  I had detailed my regular set of activities in the morning, including meditation and the setting of three key priorities, and in the evening of reflecting on my performance with those priorities.  Many folks mentioned that they had morning and perhaps evening routines, but said they had not thought about reflection - let alone intentional reflection.

My contemplation of those comments was brought into focus a bit when I came across a passage in the book Kurt Vonnegut: Letters, edited by Dan Wakefield.  It's a fascinating, funny, and, since it's Vonnegut, sometimes freaky book that takes you inside the mind of the famous author.  The passage of import is a letter he wrote to his wife Jane where he describes his daily routine.

In an unmoored life like mine, sleep and hunger and work arrange themselves to suit themselves, without consulting me. I’m just as glad they haven’t consulted me about the tiresome details. What they have worked out is this: I awake at 5:30, work until 8:00, eat breakfast at home, work until 10:00, walk a few blocks into town, do errands, go to the nearby municipal swimming pool, which I have all to myself, and swim for half an hour, return home at 11:45, read the mail, eat lunch at noon. In the afternoon I do schoolwork, either teach of prepare. When I get home from school at about 5:30, I numb my twanging intellect with several belts of Scotch and water ($5.00/fifth at the State Liquor store, the only liquor store in town. There are loads of bars, though.), cook supper, read and listen to jazz (lots of good music on the radio here), slip off to sleep at ten.

Of course most people have routines, and many people like learning about the routines of famous or successful people.  One common characteristic that most people know of is that they are almost invariably early risers - Winston Churchill being the exception as someone who loved to stay in bed until 11am.  I tend to agree - my favorite, and most productive, time of the day is between 4 and 8 am.

benfranklinBenjamin Franklin is famous for his routine, which he meticulously tracked on a daily log.  Yes, that does look remarkably similar to a leader standard work sheet, doesn't it?  Notice the two tasks on the left.

The morning question, What good shall I do today?

The evening question, What good have I done today?

In other words, setting tasks for the day in the morning, and reflecting on them in the evening.  When you search for the routines of successful (however defined) people, that evening reflection is also a common attribute.

Reflection, along with gratitude as I previously discussed, is a key attribute of leadership success.

Many, if not most, people have daily routines.  It is the reflection at the end of the day that makes it an intentional routine.  That intentionality is also a core component of mindfulness.  An awareness of the routine itself, instead of being simply a habitual series of activities.  Reflection looks back at the process and results and, most importantly, provides the introspection and analysis to improve the routine and performance generated by the routine.

How did the routine affect performance against the key tasks for the day?  How effective is that task selection itself?  How can the routine be improved to better support task completion?

Reflection, hansei in the lean world, is a powerful professional leadership tool.  It's how we look back on projects and performance, and identify ways to improve.  But it is also a powerful, and critical, personal leadership characteristic to improve daily performance.

Reflection converts simple habits into an intentional, high performing, routine.  It's worth a few minutes each evening.

Categories: Blogs

Puzzle Game:: The Impossible Room

Agile Complexification Inverter - Sun, 12/14/2014 - 02:52
My progress in The Impossible Room - iOS app puzzle game by Maruf Nebil.

“Only one room
 Only one way
 Key is alive
 Leave or stay"

Spoiler Alert --- some puzzles are solved below.
Day 1.

Collected Items ————paper scraplamp shadescrewdrivertesla bookUSB cord

Book Shelf  - opens Screwdriver-------------------------------------Aristotle  384 BCERoger Bacon  1214 - 1292Leonardo Da Vinci  1452 - 1519Copernicus  1473 - 1543Galileo  1564 - 1642Newton  1642 - 1727Faraday  1791 - 1867Tesla  1856- 1943Alan Turing  1912 - 1954Stephen Hawking  1942

 3 Stars - 5 points; ball on one point - 1 missing star;  color of stars & books may signify the overlap of authors livesshark - pinguen - robot   - got a  USB cord in drawer(^^^)   <(“)   :|]

Bird - Dog - Elephant - Dolphin   (brown yellow gray blue)A-Z  4-charblue red green  3 colors0-9   7 numbers4 greek letters -  Theta, Sigma, Psi, OmegaTh, S, Ps, O9, 200, 700, 800

Picture of sheep man dog house trees clouds
by Egidio Graziani6 places  (sheep, man, dog, house, tree, cloud)alphabetical order  (cloud, dog, house, man, sheep, tree)order in picture  left to right, eye flowing, front to back
buttons rotate in this order:   cloud, sheep, dog, tree, man, house....

Table with Globe - gave a board with numbers (1-6)golf ball  micro phone  oscar statue  W7 letters A-Zphonic alphabet   Golf, Mic, Oscar  GMOW    GMO  over Whiskey
Globe - six symbols

mirror over 4 drawer chestdrawer 1 top  8 point double ring w 4 push buttonsdrawer 2  3 blocks, 7 bundle, CBA, dart board   4 digitsdrawer 3  4 x 4 buttonsdrawer 4 4 x 4 buttons labeled ABCD  1,2,3,4  (Nice Room)

left side of bed clock with one hand000  000  00dial lock
above bed - picture of man and sheep  (moves left right up down)  center above bed
right of bedbox 9 box form letters  two buttons

5 x 7  white gray black buttons on boxempty shelfbox with  cyan red yellow  triangle

dart board  score = 172triple 18 double 15triple 16double 14twelve

8 segment clock with 3 hands   3:5:7  =  3/8 : 5/8 : 7/8big hand on 3med hand on 5small hand on 7
Day 2.

Largely learned nothing... except there is a really good cheat site:  AppUnwrapper

Yeah, OK, I used a few of the cheats - but that's not a lot of fun...

Oh - and many of the puzzles have additional clues or items to pick up once opened.  These items/clues are not visible until the lock is opened.  For example a clue written on the back of the door.

Day 3.

I have two games running.  So I took the opportunity to run a few experiments.

I had the Globe open in game A.  In the second game, B, I keyed in the sequence of buttons for the Globe but it didn't open. Then I went over to the picture on the sheep, man and dog and applied the number overlay - POP! the Globe opened.  What does this tell us?  That locks are turned off by default and actions must turn the locks on.  Such as the Globe, which was turned on by the number overlay being applied to the painting.

So... off to solve a 4 equation; 4 variable problem.

The bottom drawer (right of bed):

1) 48 x + 88 y + 2 z + 7 a = 86
2) 55 x + 4 y + 71 z + 86 a = 23
3) 6 x + 87 y + 28 z + 88 a = 4
4) 3 x + 26 y + 81 z + 74 a = ?

OPPS that didn't work out

CBA code is solved by hint
2a + c = 113
a + 2b = 93
b + 2c = 61

a = 47; b = 23; c = 19  -->  192347 = CBA

Categories: Blogs

R: Time to/from the weekend

Mark Needham - Sat, 12/13/2014 - 22:38

In my last post I showed some examples using R’s lubridate package and another problem it made really easy to solve was working out how close a particular date time was to the weekend.

I wanted to write a function which would return the previous Sunday or upcoming Saturday depending on which was closer.

lubridate’s floor_date and ceiling_date functions make this quite simple.

e.g. if we want to round the 18th December down to the beginning of the week and up to the beginning of the next week we could do the following:

> library(lubridate)
> floor_date(ymd("2014-12-18"), "week")
[1] "2014-12-14 UTC"
> ceiling_date(ymd("2014-12-18"), "week")
[1] "2014-12-21 UTC"

For the date in the future we actually want to grab the Saturday rather than the Sunday so we’ll subtract one day from that:

> ceiling_date(ymd("2014-12-18"), "week") - days(1)
[1] "2014-12-20 UTC"

Now let’s put that together into a function which finds the closest weekend for a given date:

findClosestWeekendDay = function(dateToLookup) {
  before = floor_date(dateToLookup, "week") + hours(23) + minutes(59) + seconds(59)
  after  = ceiling_date(dateToLookup, "week") - days(1)
  if((dateToLookup - before) < (after - dateToLookup)) {
  } else {
> findClosestWeekendDay(ymd_hms("2014-12-13 13:33:29"))
[1] "2014-12-13 UTC"
> findClosestWeekendDay(ymd_hms("2014-12-14 18:33:29"))
[1] "2014-12-14 23:59:59 UTC"
> findClosestWeekendDay(ymd_hms("2014-12-15 18:33:29"))
[1] "2014-12-14 23:59:59 UTC"
> findClosestWeekendDay(ymd_hms("2014-12-17 11:33:29"))
[1] "2014-12-14 23:59:59 UTC"
> findClosestWeekendDay(ymd_hms("2014-12-17 13:33:29"))
[1] "2014-12-20 UTC"
> findClosestWeekendDay(ymd_hms("2014-12-19 13:33:29"))
[1] "2014-12-20 UTC"

I’ve set the Sunday date at 23:59:59 so that I can use this date in the next step where we want to calculate how how many hours it is from the current date to the nearest weekend.

I ended up with this function:

distanceFromWeekend = function(dateToLookup) {
  before = floor_date(dateToLookup, "week") + hours(23) + minutes(59) + seconds(59)
  after  = ceiling_date(dateToLookup, "week") - days(1)
  timeToBefore = dateToLookup - before
  timeToAfter = after - dateToLookup
  if(timeToBefore < 0 || timeToAfter < 0) {
  } else {
    if(timeToBefore < timeToAfter) {
      timeToBefore / dhours(1)
    } else {
      timeToAfter / dhours(1)
> distanceFromWeekend(ymd_hms("2014-12-13 13:33:29"))
[1] 0
> distanceFromWeekend(ymd_hms("2014-12-14 18:33:29"))
[1] 0
> distanceFromWeekend(ymd_hms("2014-12-15 18:33:29"))
[1] 18.55833
> distanceFromWeekend(ymd_hms("2014-12-17 11:33:29"))
[1] 59.55833
> distanceFromWeekend(ymd_hms("2014-12-17 13:33:29"))
[1] 58.44194
> distanceFromWeekend(ymd_hms("2014-12-19 13:33:29"))
[1] 10.44194

While this works it’s quite slow when you run it over a data frame which contains a lot of rows.

There must be a clever R way of doing the same thing (perhaps using matrices) which I haven’t figured out yet so if you know how to speed it up do let me know.

Categories: Blogs

R: Numeric representation of date time

Mark Needham - Sat, 12/13/2014 - 21:58

I’ve been playing around with date times in R recently and I wanted to derive a numeric representation for a given value to make it easier to see the correlation between time and another variable.

e.g. December 13th 2014 17:30 should return 17.5 since it’s 17.5 hours since midnight.

Using the standard R libraries we would write the following code:

> december13 = as.POSIXlt("2014-12-13 17:30:00")
> as.numeric(december13 - trunc(december13, "day"), units="hours")
[1] 17.5

That works pretty well but Antonios recently introduced me to the lubridate so I thought I’d give that a try as well.

The first nice thing about lubridate is that we can use the date we created earlier and call the floor_date function rather than truncate:

> (december13 - floor_date(december13, "day"))
Time difference of 17.5 hours

That gives us back a difftime…

> class((december13 - floor_date(december13, "day")))
[1] "difftime"

…which we can divide by different units to get the granularity we want:

> diff = (december13 - floor_date(december13, "day"))
> diff / dhours(1)
[1] 17.5
> diff / ddays(1)
[1] 0.7291667
> diff / dminutes(1)
[1] 1050

Pretty neat!

lubridate also has some nice functions for creating dates/date times. e.g.

> ymd_hms("2014-12-13 17:00:00")
[1] "2014-12-13 17:00:00 UTC"
> ymd_hm("2014-12-13 17:00")
[1] "2014-12-13 17:00:00 UTC"
> ymd_h("2014-12-13 17")
[1] "2014-12-13 17:00:00 UTC"
> ymd("2014-12-13")
[1] "2014-12-13 UTC"

And if you want a different time zone that’s pretty easy too:

> with_tz(ymd("2014-12-13"), "GMT")
[1] "2014-12-13 GMT"
Categories: Blogs

What is the Agile Way to Adopt Agile?

Scrum Breakfast - Sat, 12/13/2014 - 16:41
 just posted an interesting question on the Stoos linkedin group. "What is the agile way to adopt agile?" Her answer did not resonate much with me, so I'd like to share I start a company down the agile path.

Agile is about people, both the people doing the work ("People and Interactions over Process and Tools") and the beneficiaries of the work ("Our highest priority is to satisfy the customer through early and continuous delivery...."). I believe people's own experience makes the most convincing arguments.

So I start by asking the people involved what has worked for them in the past. I ask them to remember their best projects and share the stories of those projects with other people in the room. (See Remembering Heaven for a description of how I do it). After hearing everyone's best projects and identifying the most promising role models for moving forward, we reflect on the patterns that made those projects successful.

Most people are not currently working on their best project ever. In fact, usually only about 10% of the people in the room are currently working on a great project. Very often no one at all is currently working on their best project ever. (I have seen numbers as high as 50%, but the difference between 10% and the higher score has always been a group doing Scrum!)

Would you like to be working now on your best project ever? Most people would! Could you agree to implement the patterns which made your best projects so awesome? Most people are willing to do that.

Wait! What exactly have we agreed to? Well at this point, I start to introduce Scrum (my favorite place to start), not as a set a of roles and processes, but rather as a small set of patterns. These patterns are easy to recognize in people's own successful projects. What patterns do we find?

  • Deliver something that works regularly
  • Inspect and Adapt regularly
  • A small interdisciplinary team solves the problem
  • Once voice speaks for the customer / user / stakeholders
  • High performance is achieved through continuous improvement 

So now agreeing to do Scrum is quite easy, and we can start without any significant resistance. Why?People recognize Scrum as a place they want to be, because it is a place they have already visited and liked: A great project where work is fun.

Categories: Blogs

SAFe 4.0 WIP: SAFe Principles

Agile Product Owner - Fri, 12/12/2014 - 19:20

In working towards the next release of SAFe (V4.0, scheduled for release in August of 2015), we’ve been extracting and refining the immutable Lean-Agile principles on which SAFe is based. In so doing we’ll be able to make Principles and Practices clear and distinct, and further elaborate the principles (like “Limiting WIP” ) without worrying about elaborating the principle in the body of a particular article. Plus many principles underlie many articles, so this is the way we can handle the many to many pricnipels-to-practices problem. This Guidance page captures our work in process towards that goal.

In 4.0, we’ll move them from Guidance. Our current thought is to be able to link to the principles from the BP itself and also via a modal on the left, but that design decision is deferred for now.

Categories: Blogs

News update 2014/12 – Scrum Sense merges with agile42 - Peter Hundermark - Fri, 12/12/2014 - 17:01

We are extremely delighted to announce that Scrum Sense will merge with agile42, a leading international agile consulting organisation. agile42 is headquartered in Berlin and already operates throughout Europe and North America.

The change is effective immediately. During 2015 the agile42 brand will be introduced to South Africa and over time the well-known Scrum Sense brand will be wound down.

agile42 logo


Peter HundermarkQuoting Peter Hundermark, Agile coach and founder of Scrum Sense: “This is the most exciting time for us since founding Scrum Sense in 2007. In seeking a partner I was adamant to find an organisation that shared our philosophy of helping our clients to help themselves. Being part of the awesome agile42 family will bring key benefits to our local clients.”



Andrea TomasiniAndrea Tomasini, co-founder and strategic coach at agile42, added: “Peter and I have known each other since 2008 and have collaborated before in our community work for the Scrum Alliance. With this addition we will have 8 Certified Scrum Trainers, 7 Certified Scrum Coaches and 2 Kanban Coaching Professionals. This is the largest collection of top-level certified professionals in a single organisation. Moreover, we have developed a powerful set of consulting products including the Team Coaching Framework™ and the Enterprise Transition Framework™that help our clients achieve better outcomes faster than before.”

Please read the full joint press release.

Scrum Coaching Retreat Cape Town


Don’t forget about the Scrum Coaching Retreat taking place in Franschhoek on the 09-11 Feb 2015. If you are an experienced or aspiring Agile coach, the retreat will offer an opportunity to collaborate with like minded individuals, think deeply and come away with a new perspective. For more information and to book online please follow this link. Be sure to book your place soon as space is limited!

We have had a very busy & eventful year, and are looking forward to the exciting changes 2015 will bring. We would like to thank you for your continued support and wish you and your families a wonderful festive season and great start to the New Year!

Happy Holidays!

Upcoming Courses Certified Scrum Master (CPT)
26-27 Jan 2015
Steenberg Hotel, Cape Town

Certified Scrum Master (JHB)
03-04 Feb 2015
FNB Conference & Learning Centre, Sandton

Certified Scrum Product Owner (CPT) 23-24 Feb 2015
Steenberg Hotel, Cape Town


Certified Scrum Master (JHB)
10-11 Mar 2015
FNB Conference & Learning Centre, Sandton


Course Schedule and Book Online


The post News update 2014/12 – Scrum Sense merges with agile42 appeared first on ScrumSense.

Categories: Blogs

Real Agility – Self-Organizing Team Creation Event for Large-Scale Agile Enterprises

Learn more about our Scrum and Agile training sessions on

In 2005 I had the privilege to participate in the first occurrence of this fantastic technique for organizing large numbers of people into Agile teams.  It happened at Capital One in Richmond Virginia and my colleague of the time, Kara Silva, led this successful experiment.  The problem was that the “teams” that management had set up didn’t make much sense from an Agile perspective.  They were functional teams (e.g. a team of testers).  But to do Agile well, they needed cross-functional, multi-skilled teams that could work well together to deliver great results each iteration.  So Kara and a few other senior people got together all the staff in the department into a big room with a big whiteboard and facilitated a 3 hour meeting to sort out who would be on which team.  Everyone was involved – all the people who would be on the teams were in the room.  Those teams stayed together with the same membership long after that meeting.

This “team creation event” was a fantastic success for that particular department.  What made it a success?

  1. Everyone participating already had Agile training and experience.  They knew what they were getting into and why they were doing it.
  2. Everyone was encouraged to participate through the way the meeting was facilitated.  No one felt like their opinion was ignored.
  3. The meeting was long, but also time boxed.  It wasn’t an open-ended discussion that could go forever.
  4. It was in-person!!!  Everyone was physically present so that not just abstract facts, but also feelings were clearly visible to everyone else.
  5. It was honest: tough things were discussed including potential personality conflicts.  This open discussion required expert facilitation.
  6. Management was not involved in the decision-making during the meeting.
  7. The overall purpose of the exercise was clear: here’s the business we’re in, and here’s the people we have to work with – how can we organize ourselves to be most effective?
  8. A big diagram of the proposed teams and their membership was constantly being updated on a whiteboard: visual and concrete for everyone to see.
  9. Preparation: the meeting was scheduled far enough in advance that everyone could make it and management was informed about how important it was (don’t schedule over top of it!)

In the Real Agility Program, the team creation event is used to launch a Delivery Group.  The key people at the meeting include all the potential team members as well as the three Real Agility Coaches from the business, from technology, and from process/people.  Depending on the number of people involved, the team creation event can take anywhere from two hours up to a full day.  Longer is not recommended.  For larger Delivery Groups, we recommend that the team creation event be held off-site.

Facilitation of the team creation event is usually done by the process/people Real Agility Coach.  If you wanted to use this process with other enterprise Agile frameworks such as SAFe (Scaled Agile Framework) you would have the “equivalent” person such as SAFe’s Release Train Engineer as the facilitator.

The team creation event should only be done when the business is ready to get a Delivery Group started on actual product, project or program work.  If there is any significant delay between the team creation event and the launch of the Delivery Group on it’s work, then the teams can fracture and you may need to run the event again.  A few days should be the maximum delay.

One client we worked with ran the team creation event but had some significant problems afterward because they weren’t really ready.  In particular, they still had to make staffing changes (primarily letting go of some contractors, hiring some new full-time employees).  As a result, the teams created in the team creation event were not really properly stable.  This caused a great deal of disruption and even significant morale problems for some teams.  It is essential that the Leadership Team be committed to keeping the team membership stable for a significant period of time after the team creation event.  That includes any necessary means to encourage people who are thinking of leaving to reconsider.  It also includes a commitment from leadership to respect the self-organizing choices made during the team creation event unless there is an extremely urgent problem with the results.

So, to make it systematic, here are the steps required to run a team creation event:


  1. Make sure that everyone who will participate has Agile training and has been on an Agile team for at least a few iterations/sprints/cycles.
  2. The Leadership Team needs to publish a notice (usually through email) explaining the upcoming team creation event and their unqualified support for the event.
  3. The people/process Real Agility Coach needs to schedule the time for the event, and if necessary, book the venue.
  4. In the weeks and days leading up to the event, some communication should be provided to all the participants about the overall business purpose of the Delivery Group.  Is it for a specific Program?  If so, what is the objective of the program from a business perspective?  It should not just be a one-time communication.  This should come from the business Real Agility Coach.
  5. The Leadership Team needs to decide which management stakeholders will attend the team creation event and make presentations.  These presentations should be about setting a vision for the Delivery Group, not about assigning people to teams.


  1. The team creation event starts with the people/process Real Agility Coach welcoming people and reiterating the purpose of the event.
  2. Management stakeholders make their presentations to ensure that participants have a clear vision.
  3. The business Real Agility Coach summarizes the vision presented by the management stakeholders.
  4. The people/process Real Agility Coach provides instructions about the constraints for a good Agile Delivery Team:
    • Cross-functional
    • Multi-skilled (see the Skills Matrix tool for ideas here).
    • Correct size (usually 7 +/- 2).
    • People who want to work with each other.
    • People who want to work on that particular team’s goal (if such is set).
    • Everyone must be on a team.
    • Every team must choose the people who will fill the Agile Delivery Team roles (e.g. ScrumMaster and Product owner for Scrum Delivery Teams).
  5. Everyone starts self-organizing!  Usually the three Real Agility Coaches circulate through the teams as they are working to organize themselves to offer gentle guidance, to answer questions, and to see if there are opportunities to optimize across teams.  These optimization opportunities should always be offered as suggestions rather than being directive.
  6. As the self-organization is happening, the people/process Real Agility Coach needs to clearly indicate the passage of time so that people are “finished” when the time has run out.
  7. Once the self-organizing is done, the Leadership Team (or a representative) thanks everyone for their work in creating the teams and agrees to let everyone know within a short period of time if there are any changes required (to be done before the teams start working).
  8. The people/process Real Agility Coach closes the meeting.  It is critical to record the final results of who is on which team.  It may be easiest to get the teams themselves to do this before leaving the meeting.


  1. The people/process Real Agility Coach makes sure that the Leadership Team receives a complete and accurate record of the results of the team creation event before the end of the day.
  2. The Leadership Team reviews the results and makes any (minor but critical) adjustments within a few days, at most, and publishes the final list to everyone.  Failure to do this in a timely manner can deeply demoralize the staff who will be in the Delivery Group.
  3. Any updates to org charts, management tools, time tracking tools, job descriptions, etc. that need to reflect the new team organization should also be made immediately and certainly before the Delivery Group starts working.
  4. A final thank you message from the Leadership team should be delivered immediately prior to the start of the Delivery Group doing its work.

Have you experienced an event like this? Did it work? What was different from what I described?

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

Extreme Engineering - Building a Rube Goldberg machine with scrum

Xebia Blog - Fri, 12/12/2014 - 16:16

Is agile usable to do other things than software development? Well we knew that already; yes!
But to create a machine in 1 day with 5 teams and continuously changing members using scrum might be exciting!

See our report below (it's in Dutch for now)


Extreme engineering video



Categories: Companies

Walking the Tightrope: Balancing Agility and Stability

Sonar - Fri, 12/12/2014 - 14:22

About a year ago we declared a Long Term Support (LTS) version for the first time ever, and recently, we declared another one (version 4.5.1). But we never talked about what LTS means or why we did it.

Here’s the story:

SonarSource is an agile company. We believe deeply in the agile principles, including this one:

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

So that’s why we deliver a new version about every two months. We know we need to get our changes out to the users so they can tell us what we’ve done well, and what we haven’t. (Feedback of the latter kind is more frequent, but both kinds are appreciated!) That way we can fix our goofs before they’re too deeply embedded under other layers of logic to fix easily.

That’s the agility part: release frequently and respond to customer feedback. But what about stability?

We know that many of our users are in large organizations. Since many of us came to SonarSource from large companies, we understand how well such organizations deal with frequent change: not well at all, sometimes. Instead, they need stability and reliability.

For a while, that left us with a conundrum: how could we be responsive to the customer need for stability, and still be agile?

(Drum roll, please!) Enter the LTS version.

An LTS version marks a significant milestone for us: it means that through incremental, we’ve brought a feature set to completion, and worked out the kinks. The vision that was established (a year ago, in this case) has been achieved, and it’s time to set out a new vision. (More on that soon!)

Once a version is marked LTS, we pledge to maintain it and fix any non-trivial bugs until the next LTS version is released. That way, users who need stability know that they’ll never be forced to upgrade to a non-LTS version just for a bug fix.

And if a bug fix is required for an LTS version, you know you can upgrade to it without any other change in behavior or features. I.e. it’s completely transparent to your users. Of course, we don’t mark a version LTS until we know it’s stable, and we’ve fixed all the bugs in it that we’re aware of. So the chance that you’ll need to perform this kind of transparent upgrade are small.

Of course, there are trade-offs. We release frequently, and pack a lot work into each release. By opting to stay with an LTS version, you trade benefiting from the cool new features for stability (yes, I know that’s a trade worth making for many people).

But there’s another trade-off to be aware of. When you go from one LTS version to the next, you’ll see a lot of change all at once. This time the jump from one LTS to the next includes significant UI changes, plugin compatibility differences, and changes that impact project analysis (possibly requiring analysis job reconfigurations). There’s an overview in the docs.

On the whole, a jump from one LTS to the next one will be awesome, but you need to be aware that it may not feel as trivial as SonarQube upgrades usually do. Really, it’s just a question of how you want to rip off the Band-Aid(R).

Categories: Open Source

Scrum Sense merges with agile42 - Peter Hundermark - Fri, 12/12/2014 - 11:57

agile42 logo

Scrum Sense, the foremost agile consultancy in South Africa, will merge with agile42, a leading international agile consulting organisation. agile42 is headquartered in Berlin and already operates throughout Europe and North America.

The change is effective immediately. During 2015 the agile42 brand will be introduced to South Africa and over time the well-known Scrum Sense brand will be wound down.

Marion EickmannMarion Eickmann, co-founder and CEO at agile42, commented: “We are excited to welcome well-known agile pioneer Peter Hundermark and his team to join our community. We have been most careful to ensure a good cultural fit between our two organisations. Now is the right time to join forces and establish agile42 as a truly global brand.”


Andrea TomasiniAndrea Tomasini, co-founder and strategic coach at agile42, added: “Peter and I have known each other since 2008 and have collaborated before in our community work for the Scrum Alliance. With this addition we will have 8 Certified Scrum Trainers, 7 Certified Scrum Coaches and 2 Kanban Coaching Professionals. This is the largest collection of top-level certified professionals in a single organisation. Moreover, we have developed a powerful set of consulting products including the Team Coaching Framework™ and the Enterprise Transition Framework™ that help our clients achieve better outcomes faster than before.”

Peter HundermarkPeter Hundermark, said: “This is the most exciting time for us since founding Scrum Sense in 2007. In seeking a partner I was adamant to find an organisation that shared our philosophy of helping our clients to help themselves. Being part of the awesome agile42 family will bring key benefits to our local clients:

  • The experience of agile42 with successful huge-scale agile transformations such as Ericsson and Siemens means we are equipped to better help large corporations.
  • Agile at scale requires many additional skills and consulting products. The Enterprise Transition Framework™ from agile42 provides a way for organisations to map their paths without sacrificing the emergent nature that is foundational to agility.
  • Our coaches will invest regular time cross-learning with some of the best agile coaches on the planet. This is a forge for growing our skills in the fast-paced market.
  • The Team Coaching Framework™ from agile42 is another way we will foster the growth of internal coaches at our clients, enabling them to become self-sufficient faster. This is arguably the single most important success factor in sustaining an agile transition.

We are very excited to be part of this global family of talented and passionate coaches and look forward to collaborating with them and growing the agile42 brand in South Africa.


The post Scrum Sense merges with agile42 appeared first on ScrumSense.

Categories: Blogs

NeuroAgile Quick Links #8

Notes from a Tool User - Mark Levison - Fri, 12/12/2014 - 00:25

NeuroAgile Quick Links from Certified Scrum Trainer Mark LevisonA collection of links to interesting research from the world of neuroscience and behavioural psychology that can be applied (or not) to Agile Teams.


Categories: Blogs

R: data.table/dplyr/lubridate – Error in wday(date, label = TRUE, abbr = FALSE) : unused arguments (label = TRUE, abbr = FALSE)

Mark Needham - Thu, 12/11/2014 - 21:03

I spent a couple of hours playing around with data.table this evening and tried changing some code written using a data frame to use a data table instead.

I started off by building a data frame which contains all the weekends between 2010 and 2015…

> library(lubridate)
> library(dplyr)
> dates = data.frame(date = seq( dmy("01-01-2010"), to=dmy("01-01-2015"), by="day" ))
> dates = dates %>% filter(wday(date, label = TRUE, abbr = FALSE) %in% c("Saturday", "Sunday"))

…which works fine:

> dates %>% head()
1: 2010-01-02
2: 2010-01-03
3: 2010-01-09
4: 2010-01-10
5: 2010-01-16
6: 2010-01-17

I then tried to change the code to use a data table instead which led to the following error:

> library(data.table)
> dates = data.table(date = seq( dmy("01-01-2010"), to=dmy("01-01-2015"), by="day" ))
> dates = dates %>% filter(wday(date, label = TRUE, abbr = FALSE) %in% c("Saturday", "Sunday"))
Error in wday(date, label = TRUE, abbr = FALSE) : 
  unused arguments (label = TRUE, abbr = FALSE)

I wasn’t sure what was going on so I went back to the data frame version to check if that still worked…

> dates = data.frame(date = seq( dmy("01-01-2010"), to=dmy("01-01-2015"), by="day" ))
> dates = dates %>% filter(wday(date, label = TRUE, abbr = FALSE) %in% c("Saturday", "Sunday"))
Error in wday(c(1262304000, 1262390400, 1262476800, 1262563200, 1262649600,  : 
  unused arguments (label = TRUE, abbr = FALSE)

…except it now didn’t work either! I decided to check what wday was referring to…

Help on topic ‘wday’ was found in the following packages:

Integer based date class
(in package data.table in library /Library/Frameworks/R.framework/Versions/3.1/Resources/library)
Get/set days component of a date-time.
(in package lubridate in library /Library/Frameworks/R.framework/Versions/3.1/Resources/library)

…and realised that data.table has its own wday function – I’d been caught out by R’s global scoping of all the things!

We can probably work around that by the order in which we require the various libraries but for now I’m just prefixing the call to wday and all is well:

dates = dates %>% filter(lubridate::wday(date, label = TRUE, abbr = FALSE) %in% c("Saturday", "Sunday"))
Categories: Blogs

Quarterly Product Update: December 2014

In this webinar, Jon Terry, LeanKit’s COO, provides an overview of recent enhancements and gives insight into what’s ahead. During this discussion, you’ll learn:  About our ongoing activity to deliver enhanced LeanKit reports and dashboards to you How LeanKit mobile apps help you see all your work in one place and update your work offline Current plans to help you visualize and track what’s important […]

The post Quarterly Product Update: December 2014 appeared first on Blog | LeanKit.

Categories: Companies

Secret Sauce of Running a Great Scrum Team

Agile Management Blog - VersionOne - Thu, 12/11/2014 - 20:09

In this guest post by Jeff Sutherland, co-creator of Scrum and CEO of Scrum, Inc., you will learn five reasons why 49% of agile projects fail – and how you can avoid it.

jeff sutherlandMy book, “Scrum: The Art of Doing Twice the Work in Half the Time,” was published in October. Over the last six weeks, I’ve been touring the U.S. and Europe telling the story of all the influences that culminated in the creation of the first Scrum team over 20 years ago. No matter where I go, people ask me what the secret is to running a good Scrum. The secret sauce of running a great Scrum Team is Getting to Done!

Bad Agile

There is a lot of “bad agile” out there. According to Jim Johnson at The Standish Group, 49% of agile projects fail. Why? Because people don’t grasp the essence of what it means to be agile. It requires a fundamental shift in thinking. The second value of the Agile Manifesto is quite clear: Working software over comprehensive documentation. That means that at the end of each and every Sprint you have potentially shippable increments that work!

Working software is key because it is the catalyst for one of the most important aspects of the Scrum Framework: feedback. If you don’t have working software at the end of the sprint, stakeholders can’t use it during the Sprint Review and, as a result, can’t give the Product Owner and team the feedback that will allow the team to develop the product into the customer’s sweet spot.

The secret to working software is complete testing inside the Sprint. If your agile testing practices aren’t tip-top, your teams are probably struggling, your customers are probably frustrated, and you most likely don’t know when the product will ship.

Five Causes of Team Failures

1.  Poor definition of DONE
2.  Stories not READY
3.  Dysfunctional Leadership
4.  Technical Debt
5.  Ineffective coaching

A rigorous definition of Done includes working tested product at the end of the Sprint. Teams must work together to refine their definitions of Done. Product Owners have to stop accepting Stories that don’t meet these criteria.

Good definitions of Ready and Done are two levers that produce successful Sprints. Stories don’t magically become Ready; they need to be clarified and granulated. Acceptance tests need to be embedded. This takes time and attention from the Team.

A leadership team that sees the benefits of going agile, but hasn’t engaged enough to shift their mindset, is a recipe for disaster. Scrum works because it allows capable workers to self-organize and determine how best to accomplish their goals. If management maintains a command-and-control mindset, a Scrum implementation will fail.

In an agile context, managers become leaders. They are tasked with setting transcendent goals for the organization, supporting the teams and removing organizational impediments. They need to determine what Scrum metrics would best bring transparency to the processes so they can hold the Product Owners responsible for value delivery and ScrumMasters responsible for velocity.

Technical debt needs to be stopped in its tracks. The discipline of having clean code every day is essential, as is completing all testing within the Sprint. Then the historic technical debt can be reduced piece by piece.

When implementing an organizational change, companies are pretty good about educating their employees but they fail to provide them with support they need to succeed. The most successful implementations not only get their workers certified but also bring in outside agile training and consulting services help to launch the teams.

A team launch includes an expert coach who helps develop the first iteration of the Product Backlog, helps the teams define what it means for a story to be both ready and done, and leads them through all the Scrum ceremonies at least once. Ideally, the coach returns periodically to fine-tune the teams’ work and take them to the next level.

In Conclusion

Systematically focusing on remediating these issues will consistently produce high performing teams with 200% to 400% improvement in production.

Failure to focus on them will add yet another team to the 49% of teams that are “Bad Agile,” leading to unhappy customers, lost revenue, and lower stock prices.

For more information, grab the recording of my recent AgileLIVE webinar: “Getting to Done – The Power of Scrum.”


Categories: Companies

Hansoft 8.2 Released

Scrum Expert - Thu, 12/11/2014 - 19:30
Hansoft has announced the release of the version 8.2 of its Agile software development tool. This release provides improved SSL handling and and makes it possible to add user groups to projects. This update includes support for the last OpenSSL version and the most secure protocol TLS 1.2. Data security is a topic Hansoft does not compromise with and SSL is used in all client server communication. In addition to the security enhancement, this release includes a feature improvement dedicated to administrators for large development environments. It is now find it ...
Categories: Communities

Play4Agile, February 20-23 2015, Frankfurt, Germany

Scrum Expert - Thu, 12/11/2014 - 18:44
The Play4Agile conference is a four-day conference for Agile and Lean coaches, facilitators, game and innovation experts who want to exchange questions, ideas and experiences on using games in teams and organizations. Play4Agile follows an unconference format where the participants can create their own conference, proposing their own discussion topics: sessions, games you want to play, game ideas you want to develop, evening activities. Play4Agile provides an open playground to inspire each other and to learn how using serious games can help us achieve our goals. Play4Agile is a gathering of ...
Categories: Communities

SolutionsIQ Acquires BigVisible to Form Largest Agile Consultancy Focused on Enterprise Transformations

BigVisible Solutions :: An Agile Company - Thu, 12/11/2014 - 17:14

We are proud to announce that on December 11, 2014, SolutionsIQ Corporation finalized the acquisition of BigVisible Solutions. SolutionsIQ CEO Charlie Rudd and BigVisible CEO Giora Morein have been discussing a shared vision for several months and finally decided that the time was right to create a single, comprehensive Agile consultancy that can definitively provide […]

The post SolutionsIQ Acquires BigVisible to Form Largest Agile Consultancy Focused on Enterprise Transformations appeared first on BigVisible Solutions.

Categories: Companies

Are We Succeeding With an Enterprise Transformation?

Leading Agile - Mike Cottmeyer - Thu, 12/11/2014 - 16:36

Over the past few years I’ve had the amazing opportunity to work with over 65 different teams in various levels of small, medium, and large businesses. In each case I was either leading the teams or advising the teams on how to become more adaptive. When I joined LeadingAgile, I was thrilled to have access to the systems and tools that Mike and Dennis had employed and discovered while working with the hundreds (if not thousands) of teams that they had coached over the years.

One of the first tools that I encountered was a set of adoption attributes that we could share with a team to would help the team learn about how teams operates when they are valuing: (1) individuals and interactions over processes and tools, (2) working software over comprehensive documentation, (3) collaboration over contract negotiation, and (4) responding to change over following a plan… or the agile manifesto.

From the adoption attributes I was able to work with a team to both show them the areas where they were seeing good adoption as well as the areas where they need to grow. This was incredibly helpful for the team and me as it provided a spot light into areas where I could target coaching while at the same time giving the team the opportunity to grant me permission to coach in that area.

As time went on, I had more and more opportunities to participate in organizational assessments that were aimed at understanding the organization’s business drivers, identifying their change management concerns, and identifying a pilot slice of the to-be value delivery structure where the enterprise transformation should start. Throughout this process I learned more and more on the adoption attributes and began thinking holistically around how to establish a repeatable system of transformation that was oriented around multiple phases of adoption.

Phase 1: Become predictable

Phase 2: Make risk and dependencies visible

Phase 3: Organize around capabilities to reduce or eliminate external dependencies

Phase 4: Streamline the delivery system

Phase 5: Fast ROI with quality and predictability (end-state business drivers)

This proved really helpful when framing up a roadmap for a transformation and thinking about it as an iterative and incremental process. I was able to work with both teams and business leaders to clarify a pathway towards the end-state that didn’t require me to solve all of the adoption problems at the same time. My initial hypothesis was that each of the phases would have different metrics to inform me that the key goal of the phase had been accomplished.

enterprise transformation

What I found, though, was that changing the metrics from phase to phase inspired confusion about how to know if the organization’s transformation was succeeding in delivering on the initial business drivers. In addition, I found that hitting phase 5 based on the adoption characteristics would indicate that a slice of the organization has adopted practices that could help deliver the business drivers in spirit; but, isn’t actually using business metrics to help them clarify along the way to ensure that they are able to deliver fast roi with quality and predictability.

My question then became, how can I best use the business drivers’ key performance indicators as a focusing point for throughout the transformation. One of the tools I came across for connecting the various perspectives of an organization’s health to the organizations KPI’s was the balanced scorecard.

So… here is my question/new hypothesis: is it true that for a transformation to really deliver the end-state goals, it needs to be measured through the organization’s balanced scorecard or other business metric dashboard? I think this is true and I also would advise that a transformation not necessarily be deemed a success until the scorecard demonstrates that the business is responding to change, accomplishing fast ROI with the desired quality and predictability within their markets.



The post Are We Succeeding With an Enterprise Transformation? appeared first on LeadingAgile.

Categories: Blogs

Collaborative Partnership between Scaled Agile and PEDCO results in Applied SAFe®

Agile Product Owner - Thu, 12/11/2014 - 16:05

For some time now we’ve seen a growing demand for context and culture-specific instances of the Framework, especially for highly complex organizations who are looking for a scalable and sustainable solution to long-term adoption of SAFe. As we’ve learned, when an organization applies Lean-Agile practices without adapting them to their actual context, they often find that over time, their processes start diverging across the enterprise, causing teams to move away from common process goals.

To help meet that demand, we have committed to exploring new entry points and approaches to adopting SAFe. Scaled Agile’s premium offering, Enterprise SAFe, does just that by filling the context gap with features that provide greater extensibility and object-level customization.

With Enterprise SAFe off the launch pad, the door is wide open for Lean-Agile innovators to leverage its capabilities into their own applications and services. Such is the case with Peter Pedross from PEDCO and Erich Meier from Method Park. Using Enterprise SAFe as a foundation, they have taken that concept of customization and extensibility to a new level with their upcoming product, Applied SAFe, now being developed through a collaborative partnership with our team at Scaled Agile.

Applied SAFe is an extended, ALM tool-agnostic implementation of the Scaled Agile Framework. It provides a customizable instance of SAFe, and is implemented as a comprehensive, executable process model. It includes all roles, activities, templates, guidelines, and milestones as defined by the SAFe methodology in order to bring the framework to life.

The product will launch in April, 2015. See the full product description here. We are very excited about how this new solution can ease the way for a fully comprehensive SAFe adoption in the enterprise.

Stay SAFe, and happy holidays,



Categories: Blogs

Knowledge Sharing

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