Skip to content

Feed aggregator

How does backlog refinement work?

Scrum Breakfast - Mon, 04/03/2017 - 09:43
Last month, at the Scrum Breakfast Club, we looked at backlog refinement, so I had an opportunity to explain the product backlog iceberg, a popular metaphor for explaining the process. All about stories and features, TFB  and NFC, and everything else you need to know on a stories voyage from epic to grain of sand.
Categories: Blogs

Invert Time Management; Schedule Energy

One can not manage Time. Why we talk like this is possible, might just lead to a billion dollar self help industry. Or we could invert the way we talk and think…

Scheduling Your Energy, Not Your Time By Scott AdamsYes that Scott Adams!
In that short article Scott give you his secret to success - it's basically free.  Now you could go out and buy a book like one of these to get other advice about your time usage.  Or - you could start by taking his (free) advice ... the decision is yours; but it's past time to make it.

The Time Of Your Life | RPM Life Management System $395 by Tony Robbins
100 Time Savers (2016 Edition) [obviously time sensitive information]Tell Your Time: How to Manage Your Schedule So You Can Live Free by Amy Lynn Andrews

See Also:
I'm Dysfunctional, You're Dysfunctional by Wendy Kaminer.    "The book is a strong critique of the self-help movement, and focuses criticism on other books on the subject matter, including topics of codependency and twelve-step programs. The author addresses the social implications of a society engaged in these types of solutions to their problems, and argues that they foster passivity, social isolation, and attitudes contrary to democracy."

Categories: Blogs

Introducing GitKraken Walk-In Stores

About SCRUM - Hamid Shojaee Axosoft - Sat, 04/01/2017 - 15:00
We were just kidding!

Of course we were! But it’s definitely no joke that we’re still offering GitKraken as a handy download you don’t need 50 diskettes to install.

We’re incredibly excited to reveal that, beginning Q1 2018, we will be offering a brand new way to get your hands on GitKraken: through a physical version of the app purchasable at actual walk-in stores!

For almost 2 years now, we’ve been offering a Git GUI – GitKraken, that we’ve constantly been updating and improving because we’re determined to provide you with the most luxurious Git client imaginable. Part of that luxury has always been about the UX. What are the fundamental UI traits that transpose to actual, physical actions that in turn make for a more efficient, simplified and robust experience for the end user?

In addition to the development of the app itself, we felt there was something missing from the way in which we provided GitKraken to our users.

Until now, our flow has been:

  1. Go to the GitKraken website
  2. Download GitKraken
  3. Install GitKraken
  4. Use GitKraken

Sound familiar? Of course, it does. It’s literally what almost every software company has you do. It’s standard and mediocre. It champions supposed ‘efficiency’ over the experience of luxury. But what do users actually want?

We needed some sound data to help us strategize. We sampled 5 members of the public, over the age of 80 years old, and asked them 4 simple questions:

  1. Is internet security important to you, or is it the most important thing in your life?
  2. Would you rather obtain and install a Git GUI client online or face-to-face?
  3. Tabs or spaces?
  4. If you were to install and configure a Git GUI on your Linux distribution, would you need expert help?

The results were pretty conclusive:

We convened a strategy meeting in which all stakeholders almost unanimously agreed that some sort of physical presence was missing from GitKraken’s marketing mix, and a casual mention of brick-and-mortar stores quickly escalated into animated discussion.

We looked at other companies who offer tangible experiences as part of their marketing and purchasing funnel. Apple was, of course, the first company who sprang to mind, and Hamid Shojaee, VP of Product, tasked himself with revising GitKraken’s roadmap accordingly. It wasn’t long before he had drawn up some compelling arguments, impressively articulated:

We quickly had an agreed plan in process, including architectural experts who would help us design the GitKraken Stores not only to look great but also to stimulate conversations among fellow Git users browsing the store.

Artist mockup of the first GitKraken store, opening Q1 2018. The entrance can be seen between the glass doors. At the back of the store is a large monitor to display visual items, and headphones are available to listen to music on iPods.

The aim of this venture is to provide a literal one-stop shop for you to purchase GitKraken (and install in-store, if you wish). The convenient and highly portable diskette format for the app will mean you can take GitKraken anywhere with you, even without wifi.

Perhaps you’re camping at a California state park. With your boxed copy of the app, you’re only ever one step away from installing GitKraken. On vacation at a hotel? You can install GitKraken on any hotel PC that has a 5.25 microfloppy drive. It really is that simple.

Here’s to the next exciting adventure!

Categories: Companies

Mean Time between Disruptions (MTD) a leadership Metric

A rant on Metric's I wish I had written...  so I'm going to just include it by reference and call it my own.

One thousand Words on Metrics

Here's a quote to get you even more interested in clicking that link...
ConclusionIn short, I find most grasping for metrics to be a reliable metric for lack of understanding of human behavior, not only that of those who would be measured but that of those who would do the measuring.If a higher-up wants a metric about a team, say, as an input to their judgment about whether the team’s work is satisfactory, oughtn’t there be some other way to tell?And if I choose nearly any metric on someone else’s behalf, doesn’t that reveal my assumption that I know something about how they do their good work better than they do?Or worse, that I prefer they nail the metric than do something as loose and floppy as “good work”? Well - will you look at that!  Yareev's even willing to apply his own metric to his work.  What a great example of a leader...
Let’s try that againNew metric (expiration = next subhead, privacy = public): I’m 0 for 1 on satisfying conclusions to this post.I’m hardly an expert on human behavior. If I were one, rather than being passive-aggressive and obstructive, I’d have a ready step to suggest to metrics-wanters, one that they’d likely find more desirable than metrics.Instead I have to talk myself down from passo-aggro-obstructo, by which time they’ve chosen what they’ll observe and the ready step I can offer is limited to encouraging them to observe the effects of their observation.Can you give me some better ideas?Here's my very special response to his request for comments.

   I'm wanting to +1 your whole rant, I'd like to nail it to the front doors, I'm thinking about a tattoo, but unsure where on my leader's body it should go...

   I have sometimes fantasied about asking the VP that want's a new metric, if it would be good for us to add one that measured their leadership of our group - I'll call this metric Mean Time between Disruptions (MTD).  MTD is calculated much like the old factory sign that said:
 "its been 1023 days since we killed someone at this factory, please be safe."   So let's start counting (I suggest in weeks) the time between a major disruption to the team.  For this basic metric we are looking at team formation dynamics (your familiar with Tuckman's Forming, Storming, Norming, Performing) and you Mr. VP desire the P word - but it comes after 3 stages of development beyond the F word).

   Let's start at the beginning and count weeks between Forming and ReForming.  You know like when you move a person on/off a team.  When you move the team's physical location, or when you give the team a new objective, then let's reset the clock.

   The metrics I've seen range from MTD = 0 to about 20 weeks for many teams I've worked with.  And Mr. VP says they desire persistent teams.

I would have put it on his site in the comments but I got a very dissatisfied error message from the system when I posted it... (wonder if he has a metric for failed comments?).

Agile in 3 Minutes  a podcast that discusses a journey toward agility (each episode in exactly 3 minutes).  I'm pondering... why does the magic number 3 come up in the Agile community so often?  Personally I feel it has to do with the Book of Armaments, chapter 2, verse 9 to 21; because 5 is right out!

See Also:
Team Metrics - Case Study
How could we measure Team Happiness?
Metrics for a Scrum Team  but don't confuse that post with Scrum Team Metrics which discusses the necessary and sufficient metric Velocity.
Do you really need a Project Management Office? (PMO effectiveness metrics)

Categories: Blogs

Big Data for Little Problems

Big Data for Little Problems

-OR- What happens when the customer has better data about the service than the provider and has better networking, better press coverage, better clout, better market reach and reputations?

(Feb 23) My good looking wife just spent 2 hours trying to straighten out Frontier's billing machine... it's not easy.  The amazing thing I observed for my recliner while sipping an adult beverage was her influencing techniques.  Now another amazingly disconsernation (not a word) is that Frontier has some awesome support people.  But oh-my-god do they have a tough job.  It's the system that has failed.  And they have to figure out how to make some legacy piece-of-crap work.
But it's not going to lead to happy satisfied customers (testify).

Her father, Jim, moved into the home with us in December, he loves Western movies, and is an encyclopedia of knowledge better than IMDB.  So we called up Frontier (our FiOS provider for 6 years) and added cable and a voice line for Jim.  We cut the cable some years ago.

That's when the troubles began, December 28th.  A techie came out to the house and worked 6 hours, all the while on a phone line to his partner back at the home office (I now understand why it required this constant contact to install the new system).  When he left we had higher speed internet (from their 50Mbpm to 150Mbpm service), cable channels - Stars Encore Western premium channel, and a voice line (old school) phone tied to a wall socket.  Most every thing seemed good.

But the ability to login to their Frontier web site and get a TV guide didn't function, as well as some other issues of seeing our account info online.  We were told to wait a few days as the data took a while to move through their systems (in Frontier's universe data does NOT move at the speed of light).

I noticed that if one tries to take their Frontier problem to Twitter, @AskFrontier is an effective defensive machine that kicks in to appease the person.  They cannot do anything except type into a twitter post, and escalate your issue to a thing referred to as "an Account Manager".  I tried that technique and received a call one week later - yes over 6 days to address an issue raised on a social media platform know for instant messaging.

@davidakoontz If you would like an Account Manager to assist you, please send us a DM. ^KLB— Ask Frontier (@AskFrontier) February 24, 2017 Once burned - twice shy... I didn't fall for this in February.

We found out last night that while we have been paying $193 for a basic plan and the Stars Western channel - that Frontier would be happy to offer us ALL their premium channels for $198.  Something that the competition Spectrum is quoting online visible with detail for about $150ish (yes I'm writing this from memory of my influencing wife's exasperation attempting to get the support person to recognize her point of view at being fleeced by Frontier).  Frontier's business model includes an interestingly complex system of quoting the cost for a service.  They encourage one to call in to talk to their pleasant but hamstrung  sells reps.  Who can only read from a screen that may change any day now on the pricing that appears to be very time dependent (you never know if tomorrow they will have a sell and better price for what you will be receiving everyday for years to come).  Now the prices and "packages" you agree to buy will not be the names and labels on your bill.  Those will be completely different and if you can find a subset of items on your bill that sum up to the $198 you thought you had agreed to - well you should work for the IRS.

After that 2+ hour conversation with a great Frontier support specialist, my very intelligent wife influence her way to some deep refunds, and what we hope will be all the movie channels that Jim could watch in a week.  Yet after 2 solid months of working with Frontier's business model - we are done.  We plan to see what the next bill shows (it's a mystery)... and when the dust settles switch to Spectrum.

The phone logs for ONE month - let the Record show:

Frontier Customer Support Line is 800-921-8101

779 minutes of my life... give or take a migraine

Jan 25, 2017
     6:45pm Outgoing Call 2 hours 25 minutes
     1:53pm Incoming Call 1 minute
     1:28pm Outgoing Call  18 minutes
     1:16pm Outgoing Call.   9 minutes
Jan 24, 2017
     10:39am Missed Call
       7:11am Outgoing Call  54 minutes
Jan 23, 2017
     4:59 pm Outgoing Call 2 hours 10 minutes

Jan 22, 2017
     11:00am. Outgoing Call. 2 hours 22 minutes
     10:34am  Outgoing Call  22 minutes

Jan 22, 2017
     10:08am Missed Call
     10:06am Missed Call
     10:00am Missed Call
      9:59am Missed Call

Jan 21, 2017 Saturday
    8:19pm Outgoing Call. 37 minutes

Jan 16, 2017
    7:00 pm Outgoing Call. 1 hour 17 minutes
    6:38pm Outgoing Call. 58 seconds
    3:59pm Outgoing Call. 40 minutes

Dec 28, 2016
     7:41am Outgoing Call  31 minutes

Dec 27, 2016
     4:09pm  Incoming Call. 43 seconds

Dec 24, 2016
     11:18am. Outgoing Call. 14 minutes

Oh - why oh why - did Steve Jobs died before he fixed the living room TV problem?  There is no GOD.  Can an 85 year old man learn to use this complex thing call a cable box remote from his recliner and almost infinite time?
 My experiences say NO, Freaking WAY!  Hell, I can't figure this complexifictor out and I've got 30 years in the computer industry making these complexifictors for companies that say the want customer satisfaction.

After spending all this time on the phone to straighten out the tech part of the service - getting one account etc.  The next month we spent hours on the phone about billing items... my wife found a great billing support person and it appeared she was understanding and had credited our account for many things (on the order of over $300) so we thought it was all behind us.

Then we received this bill.  Most of the credits have been slightly altered and we are owing hundreds of dollars again.
"That's it - that's all I can stands - I can't stands no more."   -- Popeye.

Categories: Blogs

Empower - an action; not a command

You have not empowered a person by telling them "you are empowered."  This is a classic mistake in communication.  When one does this, they misinterpret their message, "I'm empowering you..." with the action that a verb such as empowerment requires to happen.  This person is taking a short cut, by giving the platitude of empowerment in place of any action that would be view by the other as empowering.

"When told that they are empowered to do something; this message is actually interrupted to dis-empower the persons agency."How does this misinterpretation occur?  Why do we humans mess up this simple act of communication?

Let's look at an example:

For a few months I had been working with a new team of software developers at a large organization.  Like many organizations they had already done the agile/scrum thing and it didn't work for them.  Recently the leadership had built a satellite office and started from a very small pool of tenured people to grow it's new "resource" of technical people.  This time the leadership decided that hiring some experienced people that had "done Agile" and "knew how to Scrum" might give them the needed energy to actually get somewhere with the initiative.  At least these experts could teach the new people how to do agile right.  I guess I was one of these "experts" (another term for a has-been drip under pressure).

Observing the new team for a few weeks I noticed they referred to their process by the label "kanban," yet they never appeared to move any sticky notes on their board, never made new ones or retired any old stickies.  Mostly they just pointed at them and talked about something not written on the note.  It was very difficult for the outsider (me) to follow the process they were using -- or maybe they were not using any process; and I was following them -- to nowhere.  This will take a bit more observation.

Although that was several months ago, and my memory is not the best at recovering details when there is no emotion overlaying the details, believe me there was little emotion at their stand up meetings, I'd call them boring (the meetings, not the people).  I don't remember in the 4 weeks I was observing that they ever shipped any software, never spoke about a customer visit, or discussing a solution with a customer - I don't think anything they talked about ever got done.

So, I some how convinced their manager that what they were calling a process, could not be named - and that wasn't a good thing (sorry Alexander that attribute is not the same as your "quality without a name" ).  It didn't reflect any known process.  He didn't know much about the process either.  It was labeled "kanban." Yet they didn't exhibit any of the behaviors of a team practicing the Kanban process, they didn't even know what steps the process might involve.  They had also tried scrum, but "it didn't work" either.  It was very difficult to discuss these failures with the team or the manager, they were reluctant to discuss what about the process had failed, nor what actions they implemented when these failures occurred.

I made a bold assumption - they didn't know anything about the processes they were espousing they were using.  They had been to training classes, therefore they knew ... something.  They could use the new lexicon in a sentence (90% of the time the sentences made sense).  But how do you tell someone they are ignorant (with the full meaning - that they no nothing about a subject and it's not their fault for having never been exposed properly to the knowledge).  That's a crucial conversation.  I rarely handle these well - I got lucky this time perhaps.  I suggested the team join me in a workshop to talk about the practices they are using and how these map to the Agile Manifesto.  We did this exercise and branched off into many valuable conversations.  During this exercise we decided they were already being Agile, so many of their practices supported the principles of the manifesto.  So the question was not if they were Agile, but how much was enough... could they improve their agility - did they want to try something different?  Along the way of this conversation we might have arrived at an understanding of a difference of opinion, when I used words in the lexicon I had intended to imply certain meanings that they did not intend when they used the words.  We often seemed to use similar phrases but rarely meant the same things actually happened.  That level of miscommunication can be tedious to overcome, while still keeping an open mind that the other person has something valuable to offer.

For example: they had been using the word "kanban" to describe the process they were using because that was the term applied to the Rational Team Concert (RTC) - template work flow the company created.  They had chosen that workflow because it was easier to use than the complicated scrum workflow the organization's PMO created.  Turns out it had nothing to do with the development process they were using.  They finally agreed that they were not doing Scrum, and didn't really know how to do it... they hadn't learned much from the powerpoint presentation (imagine that).

I got extremely lucky with one of the leaders of this team. She said to the team, that she thought the
team should give the scrum master (me) a chance, just go along with whatever I said, regardless of how stupid it sounded. Try it for a few weeks, it wouldn't hurt, and then in a few weeks decide if it was working for the team, or not.  I learned of this leader's suggestion to her teammates only months later.  It was without a doubt the turning point in the relationship.  After this détente, the team members began to implement with ease suggestions on how they could implement Scrum.  One might say that this leader empowered me, but never said a word about it to me.

We did more workshops in a scrumy fashion, we had a board of items to complete.  We tracked these items on a board right there in the workshop space.  Sometimes we split the topics up more.

Sometimes the topic didn't get finished in the time allotted and we had to decide if it was good enough to continue with other topics and come back later to finish the discovered aspects.  We used the rate at which we were progressing day after day to predict that we wouldn't get all of the topics covered by the end of the week.  But that was good enough, because each day the team selected the most important, most valuable topics and we put off the lease valuable.  Sometimes a topic was dependent upon another item on the board and we had to cover some of a less valuable item so that the dependency was resolved.  In these workshops we covered many Agile principles, the Scrum process framework (3 roles, 3 meetings, 3 artifacts, and a lot more), engineering  practices (many originally defined by Extreme Programming gurus), local organization customs, terms, policies, and procedures.  Much of what was suggested by some agile or scrum nutjob was in contradiction with the customs and policies of the organization - at least on the surface.  Great conversations were developed where the team joined into filling the shared pool of knowledge.  This pool of knowledge now with company and agile/scrum knowledge was easily sorted into new understanding of how both systems could co-exist and interrelate.  It wasn't easy but it generally worked.

The team started understanding the process of Scrum and working toward getting stories in the backlog to done.  Slicing stories that had proven too large in the past and delivering working software to the business each sprint.  They developed the ability to easily estimate a story or an epic set of stories within minutes.  Their ability to read their task board and predict which stories (if any) were not going to get completed within their sprint time-box that they quit wasting time tracking a sprint task burndown.  They understood that if they got into a new domain that ability might be diminished and they could easily revert to tracking task aspirin (a unit of effort; not time) on a chart in the future. The team knew their velocity and could accomplish a sprint planning session in about an hour.  They could predict when they needed to spend more time in refining tough stories before planning and they learned how to slice stories for value and leave the fluff on the cutting room floor.

But all was not well with a performing team...  (cue the scary music - set up a scene with dramatic lighting) ... the manager was looking for a way to measure the team.  And as people are wonting to do... without any thought they look for a dashboard to tell them how well the "team is being run."  They want to know if the "team is being driven at their top performance", and they need some numbers to prove it.  Generally this is a warning indication that many conversations were wasted and no learning occurred,  in hindsight the wrong person was doing too much of the talking and the other didn't draw from the pool of shared knowledge but instead just admired the pool from the shore, never bothering to enter.  The team's manager wanted me to build a dashboard tool using the company's tool of record (RTC) that would give him all the numbers that prove his team is performing well.

I've made a strategic decision over the years to not become the tooling expert - especially with the bountiful assortment of tools the software project management industry offers.  Needless to say I didn't want to become an expert in RTC (a tool rumored to be on it's way out for this organization that was in their 3rd Agile adoptions curve).  I asked what this dashboard would have on it, what it would display, etc.?  The answer fit on a sticky note, because that's what I had with me... something like velocity, the backlog, and what the team is currently working on was the manager's response.

Here's my Nth mistake.... I hoped the request would dissipate as many thing in a transition tend to do, so I wasn't motivated to create a dashboard for the manager that would reproduce the team's well maintained Scrum task board.  I offered to work with him in reading the board, he attended many of the team's Scrum sessions at the board, rarely engaged but appeared attentive.

[this story will continue ...  as I've lost my round-toit --  wonder if it's with my marbles?]

See Also:

The Rise of Emergent Organizations  by Beth Comstock

The ScrumMaster - How to develop a team - by Marcel van Hove

Categories: Blogs

Blog Series: TDD and Process, Part 2

NetObjectives - Fri, 03/31/2017 - 14:57
Part 2: Basic (A)TDD Automation In part 1 we expressed a view that many people hold when it comes to the various kinds of tests that we write in a process that centers on Test-Driven Development: “Your tests can either provide you a great deal of value and precise information when they fail, or they can be more broadly useful to the organization when they are passing (when they accurately...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Effective carbon offsetting – what we’ve learned and what we’re doing

Henrik Kniberg's blog - Fri, 03/31/2017 - 12:29

Flying causes global warming. That sucks. But neverthless, we fly sometimes. Conferences, vacations, business trips. So what can we do? Well, here’s a simple rule of thumb:

  1. Fly as little as possible. Reduce the frequency & distance. Consider train for shorter trips.
  2. When you do fly, make sure you carbon offset. From wikipedia: “A carbon offset is a reduction in emissions of carbon dioxide or greenhouse gases made in order to compensate for or to offset an emission made elsewhere.”

The obvious question then is – HOW do you carbon offset? I was surprised when I dug into it.  “Traditional” carbon offsetting (buying emission credits and things like that) seems pretty useless! I couldn’t find any credible evidence that it makes a real difference! Almost like a scam.

So is there another way to carbon offset? Yes! This chart summarizes some of what I’ve learned so far. Read on for details. Got any more suggestions? Add comments. But please quantify.

(see this spreadsheet for the underlying numbers)

At Crisp we recently made a policy decision, unanimously:

  • For every flight organized by Crisp, we set aside SEK 100 per passenger-flight-hour to a carbon offset account.
  • That carbon offset account is managed by Climate Crisplet – a subset of people in Crisp who are interested in this kind of stuff and make sure the money is spent wisely. We try to maximize ROI in terms of CO2-reduction per money invested.

Why 100kr? Because flying emits about 0.23 tons of CO2eq per passenger hour <ref1, ref2, ref3>. It varies a bit depending on length of flight, speed, height, aircraft model, etc. But 0.23 tons per passenger-hour is a pretty reliable average (including radiative forcing).

CO2eq (Carbon dioxide equivalent) is the official unit of measurement for greenhouse gases. It is a way of aggregating different types of gases (such as CO2, methane, and others) into a single unit. We emit about 50 billion tons of CO2eq per year worldwide, and that’s the key driver of climate change.

So a 4-hour flight results in about 1 ton of greenhouse gas per passenger. We can’t take that specific ton back, it will stay in the atmosphere for many decades. But can we somehow pay to stop a DIFFERENT 1 ton of greenhouse gases from being emitted somewhere else? If so we’re fine right?

I’ve dug deep into this and concluded that yes, we can! And 400kr, if wisely spent, should be more than enough. Hence, 100kr per passenger-hour. We just need to be picky about HOW we spend it.

Our last conference trip involved flying 35 people to Marbella and back (9 hours of flying, there and back). So 315 passenger-hours, or 71 tons of greenhouse gases. Thanks to our carbon offsetting policy, the Climate Crisplet got 31,500kr to do something wise with. After some research we ended up doing this:

  • 3150kr (10% of the total) to Flygreenfund. They invest in aviation biofuel. This is jet fuel made from things like recycled frityrolja (how the heck do you translate that…. it’s recycled oil from deep-frying). Their estimate is that about 400kr compensates for 1 hour of flying.
    • Impact: about 8 tons (very loose calculation)
  • 28350kr (90% of the total) to Trine. They run a crowd funding platform for rental solar installations in sub-saharan Africa. The climate impact is measurable because they can calculate how much less kerosone and diesel needs to be burned when they install solar panels in a village. In this case we invested in Gamba, Zanzibar. Our investment is estimated to give 700 people clean electricity, reduce CO2 emissions by 260 tons, and give Crisp an 5.4% annual rate of return. Triple win! We’ll then reinvest that money to further reduce greenhouse gases.
    • Impact: About 260 tons (pretty specific calculation).

So our flight caused an increase of about 70 tons, and our investment will cause a decrease of about 270 tons. That’s a net win of almost 200 tons!



But wait, doesn’t that mean our price tag of 100kr per passenger-hour is too high?

Not really. Because the numbers are approximate. The are different ways of calculating this stuff, and each number comes with an uncertainty. But a 70 ton increase vs 270 tons reduction means we have a lot of margin for error! Even if the reductions were optimistic by a factor 3, we still win!

There’s also another very important factor to keep in mind: investment vs cost. Buying carbon offsets is money gone. You don’t get that back again. Same with things like flygreenfund. Trine, however, is an investment with an expected return (but with some risk of course). That means we are likely to get the money back, so we could invest it again and again! There are other companies offering similar types of services, basically handling the “hey how can I invest money and help the climate while getting a return on investment?” thing. For example Bright Sunday.

So why did we decide to spend 10% of our carbon offset money on Flygreenfund? Their impact is not as easily quantified as Trine, and there is no return on investment. But they are addressing the root cause – fossil fuel emissions from flying! And we want to support that.

Our carbon offsetting recommendation

So what’s the moral of this story? Don’t buy traditional carbon offsets? Invest in Trine? No, the learning goes deeper.

  • Have a clear and simple policy. In our case: 100kr per passenger-hour, and a team that is entrusted to manage the money.
  • Do the math. Stay clear of fluffy things like emission rights, unless someone can show you how it (physically!) causes CO2 reduction. Even when you see specific numbers, find out where those numbers come from. For example, Trine publishes their specific CO2 reduction estimates, but I asked them to walk through the underlying calculation with me (which they did willingly). Note that the climate impact varies quite a lot across their different projects.
  • Distinguish between costs and investments. A cost is only justifiable if it has a VERY clear and concrete impact, since that money can’t be reinvested later.
  • Trust is everything. Before investing, find out who is handling the money and what their motives are. Or follow in the tracks of someone else who you trust, and who has done the research for you. Feel free to follow us if you like
Categories: Blogs

Recorded Webinar: Q1 Product Update, 2017

TargetProcess - Edge of Chaos Blog - Thu, 03/30/2017 - 20:01

On March 15, we held our quarterly Product Update Webinar. Our Product Specialists went over the latest features in Targetprocess, and covered some of our upcoming plans.  You can watch the webinar recording here:

New features and enhancements:

  • My recent items & browsing history
  • Metrics
  • Connectors for integrating Targetprocess with ALM tools such as Atlassian JIRA, Microsoft TFS,CA Agile Central, and DevOps tools such as Git, GitHub, Jenkins and many others
  • Contributor user type
  • Improved Project-Team Selector for users, teams and projects
  • Lane suggestions
  • Service desk improvements
  • iOS & Android app improvements

Upcoming improvements (version 3.11.0 is now available):

  • Multiple final states (3.11.0)
  • Mention of teams (3.11.0)
  • Context improvement (3.11.0)
  • Settings remake (3.11.0)
  • Split of add/edit permissions
  • Undelete entity
  • Search improvements

Our team also answered questions from attendees throughout the webinar. Some of the more common questions have been listed with their answers below:

Q: Hi, thank you for the new github integration. Does the new integration also allow syncing from comments in both directions? Also, is it possible to create github issues via targetprocess?

A: Yes, it allows you to sync comments. Yes, it's also possible to create Github issues via Targetprocess.


Q: Can a metric or Calculated field now refer to the parent name? Ie, can a feature have a field that will contain the name of the Epic that contains the feature?

A: Hi, yes, you can do this with both - Calculated Custom Fields as well as with metrics


Q: Hi, is there a way to show total effort spent for tasks in a user story?

A: Hi! Yes. It is possible. In the User Story, you have a row which shows you the sum Effort of Tasks. For spent effort, you can use Calculated Custom Fields.


Q: My thought about multiple final states is: Hurra!!!

A: We're happy you like this update!

Categories: Companies

PMI EMEA – Rome – PMI’s Agile Future

Leading Answers - Mike Griffiths - Thu, 03/30/2017 - 18:11
I will be presenting at the PMI EMEA Congress May 1-3 in Rome on “PMI’s Agile Future”. 2017 marks an important year for embracing agile approaches by the PMI. The PMBOK® v6 Guide, set to be released in Q3 will... Mike Griffiths
Categories: Blogs

Performance Problems and Solutions in React.js

About SCRUM - Hamid Shojaee Axosoft - Thu, 03/30/2017 - 15:55
This is part 1 of a 4-part series!

This post is the first in a 4-part series looking at the performance issues that GitKraken developers faced. This post outlines the problems themselves, and subsequent posts in the series will focus on how the solutions to each problem were developed.

Part 1: The Problems

It may sound obvious, but in order to improve an app, you have to identify the pain points and precisely what is causing them.

A major issue we noticed in GitKraken was that the more a repository grew, the more everything slowed down. There were some tools we used to get more specific with what was at the root of such performance degradation; such as the Chrome dev tools in Electron, which contain a profiler that’s handy for giving you an idea of where you’re spending most of your time.

A profile of an action in GitKraken

After some investigation, it was clear that the app was spending an unwelcome amount of time tied up in React processes, frequently rendering and updating. Thankfully, React has its own tools for discovering performance issues, so we were able to move over to that to get more granular with the issues. It turned out that most of the expended time was in the graph, and that most of it was what we in the software development industry like to call wasted time. Wasted time is probably exactly what you expect it is–it’s time spent in processes that weren’t required in the first place.

In the context of React, the process was to go through a whole render cycle comprised of pulling new data, updating components, rendering, and constructing a virtual DOM. In the end, you compare the actual DOM to the virtual DOM, and you may conclude that the two DOMs are the same. That’s wasted time because no actual DOM updates needed to happen, and you just performed a bunch of work for nothing. Nothing!

This scenario was starting to creep up into seconds of wasted time. A couple wasted seconds might not seem like very much, but in Computerland, seconds of wasted time is comparable to watching season 5 of Lost: it might seem like there’s a point to it, and you’ve come this far so you kind of need to see it through to completion, but in reality it’s taking an excruciating amount of time, becoming increasingly irritating and turns out to be a genuinely bad user experience.


Anyways… The point is, at this time, every action in GitKraken would cause graph renders. That’s every action, even if no refs changed (for example, if a new PR came through, or one of the timelines on the graph updated), a whole graph refresh would still be performed. The subsequent frequency of repository refreshes, alongside the graph rendering process itself being slow, made the whole app feel slow.

Attempted Solution #1: Unmounting the graph

We tried to remedy this by unmounting the graph as something was loading. So, during that process, the whole graph component would be removed from React. That increased how fast the repository would load, but as a result, the amount of special-case application of this method would make the app code far more complicated and less sustainable long-term.

Attempted Solution #2: Flux implementation and Immutable.js

In our Flux implementation at the time, we had a store for each domain, and as a domain was updated, that update would cause a refresh of the graph. But, if you had a big refresh coming through, with multiple domain updates, you’d get a cascading effect of a graph refresh being calculated with every one of those domain updates. To put that into an actual use-case context, refreshing a repository would essentially result in around 8 graph rerenders, producing significant performance consequences in the app.

How so? A quick background about how Flux operates: There is a dispatch of data, and that dispatch goes from store to store, updating things as it goes. Each store—if its data changes—emits an event saying that some data has changed. React then responds to this event, grabbing the new data from the store and performing a render process.

This is all well and good, but the kicker here is that no subsequent store would update until that render process was fully resolved. So, for a single dispatch of data that updated multiple stores, this chaining effect would get costly. This was a fundamental bottleneck in our implementation of Flux.

This performance hit was compounded by the rendering process itself. When you grabbed new data from the store, the store would give you a deep copy of the data rather than its actual original data, to protect that original data from any mutations that may be caused by naïvely-written React components. We’ve since repented for our sins and now follow the one true path.

This deep copying proved to be expensive. When a component would get that data copy, it would perform a deep comparison between that data (copied from the store) and the data it already had, to ascertain if an update was necessary.

Though somewhat of a time-saver in the respect that it worked out whether or not an update needed to be performed, this check was in and of itself very expensive. However, this deep comparison was actually faster on average than just doing the update. All the rows (a commit in the graph would be considered a row), each made of multiple components and subcomponents, were causing multiple verifications that their data was the same. Faster, but still an expensive chain of events.

So, we decided to bring in a library called Immutable.js, which made immutable arrays and objects, allowing us to quickly compare if part of the object had changed because we could do a quick memory address comparison to see if that changed. Although this helped, it was extremely unwieldy to get shoehorned into our existing infrastructure without breaking ‘a lot of stuff’, and (you guessed it!) it was really slow to update objects. Even when batching updates using the built-in methods. This made our updates to the data actually take longer than the renders, so we had to ditch using Immutable as a solution. Womp womp.

Attempted Solution #3 (Bonus Fail): PureScript

We tried migrating lots of stuff over to PureScript. However, once we got started, we soon realized that this wasn’t going to be the right fit for our team.

So, by this point, we had established 3 solid areas that were pain points, causing performance issues that we needed to remedy:

  1. How we modified the state of the application with new data that came through.
  2. Retrieving data out of stores.
  3. Determining how to update components in the UI in as fast and efficient a way as possible.

These were the main 3 points that each required significant rethinking in how we were building the app.

The next 3 parts of this blog post series will focus on each of these issues respectively, the solutions we implemented, and how we implemented them. Subscribe to our blog to get the next 3 parts delivered to your inbox!

Categories: Companies

Don't hate the Joke - learn to tell it Well

Countless times I've heard people say they hate the Scrum joke about the pig and chicken.  Some people just can't tell a joke.

Jeff Sutherland points the fickle finger of fate at Ken Schwaber for starting this fable:

I've hated having to tell teams this joke... the lore of the Scrum pig and chicken is so pervasive that before long someone is going to call someone else a chicken (or a pig)... and then you have to tell the joke to help that person retain face... it can be quite uncomfortable for me.

I think my disdain for this joke has to do with two of American's least favorite farm animals being featured.  We call people chickens to say they have little courage.  We call people a pig to insult their appearance (clothing choices, weight, manners).  Had the joke featured a cat and dog... it would be so different - wouldn't it?

Now Jake it appears has taken this joke metaphor to a new level...  good job Jake!

See Also:
Some fun videos about Agile & ScrumScrum cartoons and fictional stories - a list
Scrum Pig and Chicken - part 1 by Jake Calabrese
Organizational Commitment: Pig and Chicken – Part 2 by Jake Calabrese
Does Your Culture Require Your Demise - Pig & Chicken part 3 by Jake Calabrese

Categories: Blogs

Agile Leadership Newsletters Posted

Johanna Rothman - Wed, 03/29/2017 - 17:43

If you only read my blog, you might not know I publish a monthly newsletter, the Pragmatic Manager. The last two issues have been on agile leadership. Take a look at Being An Agile Leader and Own Your Leadership, Part 1. Those newsletters in addition to this 5-part series culminating with Becoming an Agile Leader, Part 5: Learning to Learn may help you with your agile changes.

I wrote them so you could envision the value Influential Agile Leader might have for you. Take a look at my writing and do join us in Toronto in May. Early-bird pricing ends this week.

As always, email me if you have questions. Or, let’s have a quick chat. See Book a Meeting With Me.

Categories: Blogs

Keep Austin Agile, Austin, USA, May 25 2017

Scrum Expert - Wed, 03/29/2017 - 12:00
Keep Austin Agile is a one-day conference that takes place in Austin, Texas. This event offers various tracks for education and networking in a relaxed environment. The target audience is project...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Communities

XP Conference 2017, Cologne, Germany, May 22-26 2017

Scrum Expert - Wed, 03/29/2017 - 11:00
XP is a four-day European conference on extreme programming and Agile software development that takes place this year in Cologne, Germany. This is the event where Agile and Lean practitioners and...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Communities

Agile Day Riga, Riga, Latvia, July 7-8 2017

Scrum Expert - Wed, 03/29/2017 - 10:00
Agile Day Riga is a one-day conference focused on Agile project management and Scrum. Presentations and workshops will be in Latvian, English and Russian. Goal of this conference is to provide a...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Communities

Learning Tools beginning Exponential Growth

Learning tools are beginning to benefit from the exponential growth process of knowledge creation and transference.  Here is Seeing Theory an example of this.  Did you do well in Probability and Stats in school?  Funny enough I can predict with astonishing accuracy that a majority of you said "NO!"  I also struggled with those courses, may have repeated it a time or two.  But now with some age I find it much more fascination to study this subject.

Seeing Theory Leaning Site"By 2030 students will be learning from robot teachers 10 times faster than today" by World Economic Forum.

This is what happens when humans debate ethics in front of a super intelligent learning AI.

See Also:

TED Radio Hour : NPR : Open Source World  Tim Berners-Lee tells the story of how Gopher killed it's user base progress and CERN declared their WWW open source in 1993 April 30th, insuring it would continue to prosper.  And was it's growth exponential?

Categories: Blogs

Leadership Shootout at the Agile2017 corral

Derek "QuikDraw" Lane & I proposed this session (2 sessions actually) for the Agile2017 conference.  Wonder if you'd like to come play in the OK Corral with us?

SlideShare DeckHere's how it might go down...  Agile2017 Submission # 5835

And if you're interested... comment on this slide deck...  it's not the final answer.  In fact we may be sneaking bigger guns in to the corral under our dusters...

SlideShare deck


Leadership Style Shoot Out :: Which style best works for this context - how will you recognize it?

Where do you Stand

Let's survey the audience's Leadership styles/preferences - we will use a standard reference tool (or maybe just make it up on the fly). Getting the participants up and moving and interacting with each other and the sub-set of leadership styles described on the four flip charts in the corners of the room. We will play a few rounds of the game Constellations. This warm up exercise will most likely bring up some great question on terms and concepts, which we will answer as a group.

Examples of Models & Theories

We will present several models and approaches of Leadership - via Poster Presentations (previous done posters for models of Leadership: Examples: Situational Leadership II, Leader-Member Exchange Theory, Path-Goal Theory, Servant Leadership, etc.) compare and contrast theories of leadership with other leadership approaches: ( Situational, Skills, Style, Trait - also summarized on posters). Gathering insights from participants on experiences with these various leadership styles/traits. Using some famous examples from history and common known examples (JFK, Nixon, Washington, John Wayne, Neil Armstrong, etc).

Review of Literature

We will present a library of books (10 - 30 leadership books) to loan out for the next few days of the conference - participants wishing to come to next session (2 days later) will preform a poster book report on the topics of interest with their small group on the books best topics during the 2nd session. This technique is ripped off from my mentor Sivasailam Thiagarajan (, I'm sure he will not sue us. This game however is going to require longer than 75 min. to get value - so I'm proposing a radical new idea for conference session - a follow up session scheduled later in the week for the sub-set of participants that choose to participate in this "home-work assignment".

In the 2nd session we will organize the posters - book reviews and give each group/team about 10 min. to present and then a few min. for audience Q&A. Largely dependent on the number of small teams wishing to participate; wishing to go in depth on a topic and learn about that aspect of leadership. Then leave time for a debrief of both sessions.

Information for Program Team:

We are requesting something VERY RADICAL - 2 sessions - for ONE topic - the first session will set the hook: interest a sub set of participants to commit to the second session (the book-review report back poster extravaganza session later in the week).

First session on Monday or Tuesday; second session on Thursday or Friday - link them in the catalog with an "**" and note.

Each session will be independent enough that participant that do not want to attend the other will be carried along with the enthusiastic games of the others that have attended both. Interesting and Learning will be available for all - regardless of attendance of both sessions.

Prerequisite Knowledge:

none really - however we assume many people have been part of a group and have seen many forms of leadership in many different context

Learning Outcomes:

- Awareness of several views of Leadership and Management
- Knowledge of multiple theories of leadership
- develop a lexicon of terms to discuss leadership behaviors
- experience being an emergent leader in a group with a specific objective
- Understanding that styles of leadership change over time throughout history
- Ways to measure effectiveness of leadership (via the fellowship of followers)
- Assessment tools and models to take home and try on your leaders

Categories: Blogs

Better User Stories: 24 Hours Until Doors Close

This blog post refers to a four-part series of videos on overcoming challenges with user stories. Topics covered are conducting story-writing workshops with story maps, splitting stories, and achieving the right level of detail in user stories.

To be notified when you the videos are again available, sign up below:

Notify Me!

Just a quick post this week to let you know that we will be closing registration to Better User Stories tomorrow at 6 P.M. Pacific, 9 P.M. Eastern.

We still have spaces for the Expert and Professional Levels, but Work With Mike is now completely sold out.

Click here to register before the deadline

Just a quick reminder of what people are saying about the course:

I could squeeze videos in between meeting packed days

“I loved the acronyms used to test story quality and that the modules were broken up into small enough segments that I could squeeze videos in between meeting packed days… I really enjoyed the worksheets that forced me to use my own backlog as practice to cement the concepts in my brain. It's way too easy to go through an online course and not really retain information that is useful later but that's what made it real for me.” - Sarah Fraser

Immediately able to apply what I learned

“I've used user stories for many years. I wasn't sure if this course was really going to teach me something new… I thought if anyone is going to be able to teach me more about user stories it will be Mike Cohn… The Q&A calls with the training were great. I think this is a big differentiator to other online trainings I've done. I was immediately able to apply what I learned in this course to support teams get their backlog set up as they begin delivering using the scrum framework. - Amber Burke

If you’re on the fence, jump in…

“It has already influenced and changed how I deliver story writing workshops. There is a lot of valuable information. It is split up into logical and digestible segments. For anyone willing to put in the time that needs to understand how to write better stories; you will find value here. If you're on the fence, jump won't regret it.” - Max Lamers

You still have (some) time to access the free mini-course

When we close registration to the full Better User Stories course, we will also be taking down the free video training. If you’ve not yet seen those, you still have time to register and watch them before tomorrow’s deadline.

Click here to access the free mini-course

I don’t know when we’ll be opening doors again to the full, advanced course, so if you and your team want to sharpen your user stories skills, this is a great time to join.

Any last minute questions about the course? Let me know in the comments below.

Categories: Blogs

4 Things You Must Do At Scale

NetObjectives - Tue, 03/28/2017 - 08:36
This blog covers some of the ideas in the first session of our upcoming webinar series on Tuning SAFe. It's actually an adaptation of our Lean-Agile experience into the SAFe model so it will be useful for anyone attempting or doing Agile at scale. The first session, called 'Rationale of SAFe', discusses the four key elements of an Agile transformation. These four issues must be dealt with...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.