Skip to content

Feed aggregator

Agile is Dead, Long Live Agile

Kanbanery - Wed, 09/14/2016 - 20:30

Artykuł Agile is Dead, Long Live Agile pochodzi z serwisu Kanbanery.

For years now I’ve been hearing ever louder voices announcing the death of agile. Some have suggested that lean is the new agile. Recently, there has been a call for a new agile manifesto.
With all of this in the background of my mind, I was re-reading one of Clifford Geertz’ most famous essays while and I can’t resist quoting the opening passage in full, because it takes on a new significance for me in light of our evolving understanding of agile.

In her book, Philosophy in a New Key, Susanne Langer remarks that certain ideas burst upon the intellectual landscape with a tremendous force. They resolve so many fundamental problems at once that they seem also to promise that they will resolve all fundamental problems, clarify all obscure issues. Everyone snaps them up as the open sesame of some new positive science, the conceptual center-point around which a comprehensive system of analysis can be built. The sudden vogue of such a grande idee, crowding out almost everything else for a while, is due, she says, “to the fact that all sensitive and active minds turn at once to exploiting it. We try it in every connection, for every purpose, experiment with possible stretches of its strict meaning, with generalizations and derivatives.”
After we have become familiar with the new idea, however, after it has become part of our general stock of theoretical concepts, our expectations are brought more into balance with its actual uses, and its excessive popularity is ended. A few zealots persist in the old key-to-the-universe view of it; but less driven thinkers settle down after a while to the problems the idea has really generated. They try to apply it and extend it where it applies and where it is capable of extension; and they desist where it does not apply or cannot be extended. It becomes, if it was, in truth, a seminal idea in the first place, a permanent and enduring part of our intellectual armory. But it no longer has the grandiose, all-promising scope, the infinite versatility of apparent application, it once had.
The second law of thermodynamics, or the principle of natural selection, or the notion of unconscious motivation, or the organization of the means of production does not explain everything, not even everything human, but it still explains something; and our attention shifts to isolating just what that something is, to disentangling ourselves from a lot of pseudoscience to which, in the first flush of its celebrity, it has also given rise.
-from “Thick Description: Toward an Interpretive Theory of Culture” by Clifford Geertz

Does that sound familiar? Perhaps this is where we are now with agile. We’ve finally accepted that it’s not a panacea, and some are disappointed to learn that making software is still hard. Managing knowledge work is still messy.  Let’s apply ourselves to the task of identifying and patching the holes and accept that agile, having turned the software world on its head by reinjecting humanity into the process, is now a part of us. But our journey continues, and Kanbanery is working to address some of the most pressing gaps (or opportunities) of our post-agile world.

Artykuł Agile is Dead, Long Live Agile pochodzi z serwisu Kanbanery.

Categories: Companies

Link: Strong Teams Start With Trust

Learn more about transforming people, process and culture with the Real Agility Program

One of the positive outcomes of an agile team succeeding in its transformation is the establishment of a high-functioning team.

A high-functioning team works more effectively, efficiently and can innovate more appropriately for the corporate advantage of the business.

Ryan Yeoman has a lot to say on the topic. Although he doesn’t mention agile specifically, he’s right on in his approach.

In his article, “Strong Teams Start With Trust: 5 Ways To Build Trust in Your Teams,” he writes that:

All of them point to trust as a critical and fundamental piece to success – in business and in life.

Piggy-backing all these thoughts and making it personal to myself, trust enables me to be more.  It enables me to:

  • Accomplish more and do better work by getting feedback and synergizing
  • Grow and learn more by allowing myself to be “open” and receive information
  • Teach more and serve by letting me focus my attention on others
  • Care more and empathize because I’m not constantly worried about protecting myself
  • Be more human

Trust helps you accept deepening relationships and removes politics and silos from the work place, creating an organization within which people feel safe. At its simplest, trust is a catalyst for your organization to be more: more nimble, more efficient, more effective.  It’s like oxygen for a successful team – one simply can’t exist without it.

I found his comments insightful and his links appropriate.

This is an excellent article for those team members who are striving for excellence and learning to trust one another, and themselves, in the process.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Link: Strong Teams Start With Trust appeared first on Agile Advice.

Categories: Blogs

Financial Prioritization of Projects

TV Agile - Wed, 09/14/2016 - 17:39
One of the reasons why traditional planning fails when we manage innovative projects, is because the work reported in the plan is not prioritized by the value to the user and the customer. Many traditional plans are created with the assumption that all identified activities will be completed. Since the project customers do not care […]
Categories: Blogs

Managing Client Expectations about Agile

Scrum Expert - Wed, 09/14/2016 - 16:44
‘Agile’ is an incredibly powerful software development methodology, however the word ‘agile’ has become one of those IT buzzwords that people use but do not fully understand. How do you manage expectations for clients who are new to agile or do not fully understand the agile methodology? And, does agile work for every project? This session considers how to define an agile project methodology that fits client needs and will deliver project success. Video producer:
Categories: Communities

Running Robot Framework's Remote Server as Java agent

Xebia Blog - Wed, 09/14/2016 - 08:48
Robot Framework is a great automated testing tool that uses a keyword-driven approach. When you want to run Robot Framework tests within the context of a running system-under-test you can load Robot Framework's RemoteServer as a java agent. This is not something that comes out of the box so we will explain how to do
Categories: Companies

scikit-learn: First steps with log_loss

Mark Needham - Wed, 09/14/2016 - 07:33

Over the last week I’ve spent a little bit of time playing around with the data in the Kaggle TalkingData Mobile User Demographics competition, and came across a notebook written by dune_dweller showing how to run a logistic regression algorithm on the dataset.

The metric used to evaluate the output in this competition is multi class logarithmic loss, which is implemented by the log_loss function in the scikit-learn library.

I’ve not used it before so I created a small example to get to grips with it.

Let’s say we have 3 rows to predict and we happen to know that they should be labelled ‘bam’, ‘spam’, and ‘ham’ respectively:

>>> actual_labels = ["bam", "ham", "spam"]

To work out the log loss score we need to make a prediction for what we think each label actually is. We do this by passing an array containing a probability between 0-1 for each label

e.g. if we think the first label is definitely ‘bam’ then we’d pass [1, 0, 0], whereas if we thought it had a 50-50 chance of being ‘bam’ or ‘spam’ then we might pass [0.5, 0, 0.5]. As far as I can tell the values get sorted into (alphabetical) order so we need to provide our predictions in the same order.

Let’s give it a try. First we’ll import the function:

>>> from sklearn.metrics import log_loss

Now let’s see what score we get if we make a perfect prediction:

>>> log_loss(actual_labels,  [[1, 0, 0], [0, 1, 0], [0, 0, 1]])

What about if we make a completely wrong prediction?

>>> log_loss(actual_labels,  [[0, 0, 1], [1, 0, 0], [0, 1, 0]])

We can reverse engineer this score to work out the probability that we’ve predicted the correct class.

If we look at the case where the average log loss exceeds 1, it is when log(pij) < -1 when i is the true class. This means that the predicted probability for that given class would be less than exp(-1) or around 0.368. So, seeing a log loss greater than one can be expected in the cass that that your model only gives less than a 36% probability estimate for the correct class.

This is the formula of logloss:


In which yij is 1 for the correct class and 0 for other classes and pij is the probability assigned for that class.

The interesting thing about this formula is that we only care about the correct class. The yij value of 0 cancels out the wrong classes.

In our two examples so far we actually already know the probability estimate for the correct class – 100% in the first case and 0% in the second case, but we can plug in the numbers to check we end up with the same result.

First we need to work out what value would have been passed to the log function which is easy in this case. The value of yij is

# every prediction exactly right
>>> math.log(1)
>>> math.exp(0)
# every prediction completely wrong
>>> math.log(0.000000001)
>>> math.exp(-20.72326583694641)

I used a really small value instead of 0 in the second example because math.log(0) trends towards negative infinity.

Let’s try another example where we have less certainty:

>>> print log_loss(actual_labels, [[0.8, 0.1, 0.1], [0.3, 0.6, 0.1], [0.15, 0.15, 0.7]])

We’ll have to do a bit more work to figure out what value was being passed to the log function this time, but not too much. This is roughly the calculation being performed:

# 0.363548039673 = -1/3 * (log(0.8) + log(0.6) + log(0.7)
>>> print log_loss(actual_labels,  [[0.8, 0.1, 0.1], [0.3, 0.6, 0.1], [0.15, 0.15, 0.7]])

In this case, on average our probability estimate would be:

# we put in the negative value since we multiplied by -1/N
>>> math.exp(-0.363548039673)

We had 60%, 70%, and 80% accuracy for our 3 labels so an overall probability of 69.5% seems about right.

One more example. This time we’ll make one more very certain (90%) prediction for ‘spam’:

>>> print log_loss(["bam", "ham", "spam", "spam"], [[0.8, 0.1, 0.1], [0.3, 0.6, 0.1], [0.15, 0.15, 0.7], [0.05, 0.05, 0.9]])
>>> math.exp(-0.299001158669)

74% accuracy overall, sounds about right!

Categories: Blogs

Mishkin Berteig explains Real Agility

Learn more about transforming people, process and culture with the Real Agility Program

This video introduces some key features to the thinking behind real agility.

80 % = 90% of money and resources in an organization is going to waste and only 10% – 20% goes to productive, valuable work.

Real agility helps to solve this problem by creating a state where the amount of waste is reduced and the about of productivity is increased.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Mishkin Berteig explains Real Agility appeared first on Agile Advice.

Categories: Blogs

Youth in Agile, Part 4: Are Milliennials More Agile?

BigVisible Solutions :: An Agile Company - Tue, 09/13/2016 - 18:00

Life as a Boomer vs life as a Millennial in one gif

Boomers v. Millennials in One Gif

I have had a sneaking suspicion for a while now that the answer to this question is yes. Yes, Millennials are more Agile. Duh. But, though I felt this to be true anecdotally, I wanted to see if my gut was right. After all, data of all types is constantly available to us in this day and age of easy-access technology–and how might that have affected those of us born between 1980 and 2000? Remember when Saturday morning cartoons were choppy and laboriously hand-drawn? I get nostalgic thinking about programs like Thundercats and Transformers, and yet I can’t even make it through a sitting today. Meanwhile, the “classics” are being reinvented with technology that no one could have dreamed up before. How much has technology–not to mention the scientific advances that prop it up–shaped Millennials, their expectations, their worldview?

Entertainment is one thing, but what about the work place? In our Youth in Agile series, we set out to hear from some young voices, voices that will one day shape the future. As of 2015, Millennials are officially the largest workforce, and that is imperative to keep in mind for several key reasons.

#Millennials are the largest workforce in history–how do you tap into their values?
Click To Tweet

Millennials in the US are:

  • Digital Natives: Having grown up in the age of computers, Millennials have technology hard-wired into their brains and bodies to the extent currently possible.
  • Frugal: With education comes debt, and Millennials are suffering under a debt of historical proportions. Paired with their value system and technology, frugality is one reason why Millennials are much more biased towards affordable (often free) and/or open-source mobile applications than previous generations. 

    “25 years from now, car sharing will be the norm and car ownership an anomaly.”
    – Jeremy Rifkin, Author and Economist

  • Communal: If frugality is a value, then sharing is one way to make sure money goes far. Millennials are much more likely to value shared resources (think: Uber, shared living arrangements, open source tech of any kind) than scrape together their precious pennies to buy the “essentials” that previous generations prized (think: car, house, etc.). As this article puts it: “Many young Americans choose to call up a ride when and where they need it, saving on monthly car payments, insurance, and gas.”
  • Entrepreneurial: Whether you call it naivete, optimism, narcissism or something else, Millennials are certainly independent. They are grounded in their own values and opinionated but also generally informed. That means they also have an entrepreneurial streak that GenXers would envy.
  • Postponing Marriage/Children: Finally, Millennials tend to marry later and have children later in life. Many also feel that marriage is no longer a rite of passage that all must pass through. And kids, well, they can wait until later, when the career is where Millennials want it to be after working so hard to get degrees–and incurring so much debt in the process!

Digital natives, entrepreneurial & communal-minded – #Millennials are more Agile
Click To Tweet

Here’s what I think all that means:

Millennials have completely different motivations from previous generations. They don’t care about cars or houses or your six-figure salary–or at least not as much as their parents did. They also don’t care about the issues that divided the country before, things like race, gender identity, sexual orientation, and even some harder hitting issues. What they do care about is the commoditization of their time by others, especially people from previous generations who put up with such sordid things as waiting in lines to cash a check at the bank, showing up to meetings that have nothing to do with you, kissing @$$ because that’s how you get ahead, buying brands that other people buy. The list goes on, but the main point is that Millennials in some ways have figured out that time and money are real scarce, so they don’t want to waste any of theirs just because you say so.

So, are Millennials more Agile? Yes!

Agile is all about minimizing waste, getting more value quicker and essentially figuring out how not to leak money and time like a sieve because that’s always how it has been done before (whatever it happens to be). For Millennials the concept of Agile is moot; it’s just common sense. However, if you need further evidence in Agile terms, Millennials are:

  • Collaborative: Despite what people think, today’s global economy requires Millennials to band together and pool resources to deal with the increasingly taxing demands of present day society. Heard of the “Sharing Economy”?
  • Transparent: If Millennials are selfish or self-centered, it’s not because they didn’t tell you. Today’s youth are likely to tell you more than you’d care to know, because in the Selfie Age it’s perfectly acceptable and expected to share sordid details with those you trust. That includes weaknesses and areas for growth, which is more than can be said for those of us who think that hiding a weakness is the same as not having it.
  • Feedback-driven: Millennials can be perhaps a little too feedback-driven in my opinion. Living for Facebook likes or friend adds is shallow, don’t get me wrong, but recognizing that results can be achieved by making small changes that are sometimes just perceptual–that’s a capability everyone could benefit from.

    “Millennials think they can go in on the first day and talk to the CEO about what’s on their mind. The Generation X manager thinks, ‘What are you doing??’”
    Shara Senderoff, CEO of Intern Sushi, in this Forbes article

    Continuously learning: In 2003, Apple ran an ad with the tagline, “There’s an app for that.” And in general, that’s true. And hey, if the app doesn’t exist, you can always hire a freelance developer to make it for you. The learning curve for some applications is pretty steep, but in general today is the age of self-education, where knowledge and information are literally waiting for your consumption. Need to fix a flat tire? YouTube. Wanna get your MBA? Khan Academy. How about building a next generation robot that will fix your flat tire for you while reading your Economy textbook to you outloud? MIT OpenCourseWare. There is literally no reason to wait to learn basically anything until next quarter or next year.

Finally, and perhaps most important, Millennials are value-driven. “Millennials… want to find purpose in their toil and their career… which does not necessarily come from getting the highest possible salary or nicest office.” So if the foregoing list of value had made it into the Millennial mindset, no amount of coercion is going to make them conform to the current way of doing things. They’d much rather just change the whole system.

#Millennials are value-driven, and their values are naturally more Agile
Click To Tweet

But now that we have that covered…

Is “Agile” too Restricting for Millennials?

millennialspostgif1Agile is a word that gets thrown around a lot (something I’m guilty of), but it’s worth pointing out (again) that Agile is a mindset, not just tools and practices. Too often we equate frameworks like Scrum and Kanban with Agile, but these frameworks are just a means to an end: an Agile way of working, living and being. The frameworks, practices and tools help us internalize the real Agile values (which I believe run deeper than even those that are written in the Agile Manifesto). Agile has evolved, for better or for worse and thinking of it as a static thing that any one group of people can own is–how should I put it?–naive and self-centered. In other words, you can be Agile–transparent, collaborative, biased toward inspecting and adapting and working in an iterative, incremental manner–without ever touching a Kanban board or being part of a SAFe release train. The whole idea of Agility is changing how people approach life, collaboration and work, so when the change is in place, Agility becomes the norm and ceases to be particularly valuable in itself.

Today, Scrum and Kanban are useful frameworks for getting teams to collaborate, be transparent and focus on delivering value iteratively and incrementally. However, ritualistic ceremonies like daily standup, sprint planning and reviews may seem too restrictive to constant collaborators like Millennials. Will the workplace of the future need them?


Agile is mainstream and that is a huge step in the right direction. But it isn’t enough to say you’re Agile; the proof is in your corporate culture. That culture is key to whether you succeed in the future, which is likely to be even less predictable than the present. Like it or not, the future will be created and led by Millennials who are naturally more Agile. It requires today’s companies to look for ways to provide leadership and management that Millennials can understand, relate to and grow from. That means less micromanaging and more lenient working arrangements. It means patronizing them less and inviting them more to strategizing how to innovate for sustainability. It means creating an environment where Millennial values matter and where they have a voice in the direction of the brand and how the company can evolve. It may sound like a lot to ask, but if you don’t create an environment where the next generation of leaders, thinkers and doers can thrive, they will create it for themselves.

Create a work place where #Millennials can naturally be Agile or they’ll do it themselves
Click To Tweet

Resources and Further Reading

Millennials Coming of Age Infographic by Goldman Sachs.

“How Millennials are Changing the Global Economy” by Trevir Nath. Nasdaq.

“Agile for Millennials” by Chris Greco. Bright Hub Project Management.

“Agile management: Four areas where Millennials require a different approach” by Kelly Services.

“The 2015 Millennial Majority Workforce” (SlideShare) by Elance-oDesk.

“15 Economic Facts About Millennials” (Report) by the Council of Economic Advisers. United States Government.

“5 Things You Should Know About Millennials” by Allysia Lowe. EO Fire.


More in the Youth in Agile Series

Part 1: “Higher Education vs. the Real World” by SolutionsIQ Conner Mattingly

Part 2: “Two Eye-Opening Experiences in an Agile Work Environment” by SolutionsIQ Intern Mia Rudd


Like this? You’ll love Agile Eats

Agile Eats is our semi-monthly e-blast chock full of tips and tricks too good not to share. Subscribe now!

The post Youth in Agile, Part 4: Are Milliennials More Agile? appeared first on SolutionsIQ.

Categories: Companies

6 Crucial Elements of Tracking Business Value from Strategy through Delivery

Agile Management Blog - VersionOne - Tue, 09/13/2016 - 14:30

Do you have end-to-end visibility of business value as it flows from strategy through Agile development and DevOps delivery? Dean Leffingwell, the co-founder and chief methodologist at Scaled Agile, Inc., explains the 6 key elements of tracking the flow of … Continue reading →

The post 6 Crucial Elements of Tracking Business Value from Strategy through Delivery appeared first on The Agile Management Blog.

Categories: Companies

What’s a spike, who should enter it, and how to word it?

Leading Agile - Mike Cottmeyer - Tue, 09/13/2016 - 13:52

What’s a Spike? Who should create it? And what should it look like in VersionOne? (Or in Agile Central, Pivotal Tracker, HP AGM, Jira, or your ALM tool.)

Excellent questions! I thought I’d share my thoughts on the topic:

What’s a Spike?

Sometimes a story is too large or overly complex. Perhaps the implementation or a 3rd party tool or library is poorly understood. The team can’t estimate the story. Perhaps we’re unsure if we’ll be able to complete the story due to some potential blocker.

In these cases, we might want to build a functional or technical experiment to figure it out. We might want to look into something for a day. We might want to look up alternatives. Do some googling. Do an experiment with some other library or software package. Consider alternative refactoring paths.

These are “spikes”. You can call them research spikes, or architectural spikes, or refactoring spikes if you wish.

A spike as an investment the Product Owner makes to figure out what needs to be built and how the team is going to build it — in advance of actually building it. The Product Owner allocates a little bit of the team’s capacity now, ahead of when the story needs to be delivered, so that when the story comes into the sprint, the team knows what to do.

Therefore, a spike is an investment to make the story estimable or schedule-able.

Spikes Represent Risk

Here’s the deal with spikes though… spikes represent risk. Spikes represent uncertainty. If our backlog is full of spikes, that means that our backlog is full of stuff we don’t know how to do. If our backlog is full of stuff we don’t know how to do, our product delivery process isn’t going to be stable. It means that we have no business making commitments at the release level, because we don’t have a credible plan for getting to done.

Therefore, you generally don’t want spikes to hang around very long. I usually try to do them about as soon as I discover the need for it. I usually stick it in the next sprint, if I can’t add it to this sprint.

How to Enter a Spike

If the spike only takes, say, an hour or two, maybe we don’t need to track it in our ALM tool. If it’s larger than that, you should enter it into your backlog.

How would a BA or Product Owner write up a spike? The cocky answer is to say “make your tech lead enter it”. A more serious answer would be that the technical story format would be good:

In order to <achieve some goal> <a system or persona> needs to <some action>.

Example: In order to split the collection curve wizard story, the tech lead needs to do some detailed design. (Just enough to split the story.)

Example: In order to estimate the “user connection report” story, the tech lead and BA need to research capabilities of MSTR and have some conversations with the PO. (Just enough to estimate the story.)

I like to start the name or title with “SPIKE:” to make them stand out in the ALM tool. Using a tag or a label could work as well.

Time-box your Spikes

Teams should agree that every spike is, say, never more than 1 day of research. (For some teams this might be, say, 3 days, if that’s the common situation.) At the end of the time-box, you have to report out your findings. That might result in another spike, but time-box the experiments. If you weren’t able to answer the question before time runs out, you must still report the results to the team and decide what to do next. What to do next might be to define another spike.

You might say “I think there’s a bug in the app server… there’s no way I can hear back from their support within the time-box.” The timebox is effort, not calendar time. So, the spike can be about recreating the problem and providing enough info for the support group to look into it.

It’s also best if a spike has one very clear question to answer. Not a bunch of questions or an ambiguous statement of stuff you need to look into. Therefore, split your spikes just as you would large user stories.

You don’t have to use the whole time-box. For example, if it’s an estimate that you were after, do just enough work to give the estimate and stop.

By the way, I don’t estimate spikes, but that’s another blog post.

There you have it, an answer to what’s a spike. More than you ever wanted to know about spikes!

The post What’s a spike, who should enter it, and how to word it? appeared first on LeadingAgile.

Categories: Blogs

Agilia, Budapest, Hungary, October 12-14 2016

Scrum Expert - Tue, 09/13/2016 - 09:00
Agilia Budapest is a three-day conference focused on Agile software development. The theme of this edition is the role of product owner and product management in Agile: creating vision, designing product, managing teams, role of Product Owner, engagement of customers and users, creativity and management of innovations. Use cases. In the agenda of the Agilia Budapest conference you can find topics like “Secrets of Product Ownership”, “One Product, One Project, Two Perspectives”, “How to build a product design team and become more agile?”, “Given/When/Then-ready sprint planning”, “Quality Assurance from perspective of Product Owner”, “How Product Owners can really understand customers through Mindfulness?”, “Behavior Driven Web UI Automation with Selenium and SpecFlow/Cucumber for Java”, “Zeros to Heroes in Just Three Months: When Capability is Your Product”, “Breaking Bonds. How intrapreneurship is encouraged with practices and technology”, “Scrum allows us to create better products, more suited to the users’ needs. Really???”. Web site: Location for the Agilia Budapest conference: Budapest, Hungary
Categories: Communities

Links for 2016-09-12 []

Zachariah Young - Tue, 09/13/2016 - 09:00
Categories: Blogs

Does ES6 Mean The End Of Underscore / Lodash?

Derick Bailey - new ThoughtStream - Mon, 09/12/2016 - 21:24

If you look at the latest Chrome, Safari, Firefox and MS Edge browsers, you’ll notice the compatibility and feature implementation of ES6 is darn near complete. 

And for the majority of developers that still have to support older browsers? Babel and other pre-compilers have you covered.

There’s so much adoption among the latest browser versions, the latest node.js, and pre-compilers, that you don’t have much reason to ignore ES6 moving forward. 

But what does this mean for some of the old stand-by libraries that have not only provided great APIs and utilities, but also helped to define the feature set in ES6?

Underscore lodash trash

Tools like underscore and Lodash – are they now obsolete, with ES6 features replacing most of the utility belt that they had provided?

I have to admit – I rarely use underscore or Lodash anymore.

Other than my front-end code where I am still stuck in my Backbone / Marionette ways, I’m rarely installing underscore or Lodash into my projects, intentionally. 

Every now and then I see enough need to install one of them. But, more often than not I turn to the ES5 and ES6 counterparts for the methods that I use frequently.

For example, some underscore -> es5/es6 array methods:

  • each -> forEach
  • map -> map
  • reduce -> reduce
  • find -> find
  • filter -> filter
  • contains -> includes
  • etc, etc, etc

While the method signatures and behavior are not 100% the same, there is an unmistakable influence in the ES5/ES6 list of array methods, compared to the underscore and Lodash API.

Because of this, I have largely been able to do without these utility belts.

But I wondered if I was the exception or the rule.

I knew that my use of these libraries was limited compared to a lot of people.

After all, I’m rarely digging into the more functional / composition aspects of JavaScript. I don’t spend much time type checking with the various is* method, anymore, and frankly the various builds and advanced options of Lodash have often kept me away out of lack of time (effort) to understand them. 

I had assumptions about this, because of my own experience. But, I wanted to verify that my thoughts on “underscore is dead” were shared in the community.

So I sent out a poll on Twitter and asked,

Are you still using Lodash / underscore?

are you still using underscore / Lodash, now that ES2015 is available most places / with precompilers?

— Derick Bailey (@derickbailey)

August 31, 2016

The results shown in the poll were nothing like my own experience and expectations.


Only 9% of the 236 responses said that ES6 (ES2015) makes Lodash / underscore obsolete.

Personally, I fell into the 17% of “yes, but rarely”.

But the overwhelming majority of respondents – nearly 75% of them – said they still use these libraries frequently, with nearly half the responses wondering they they wouldn’t use them.

With the responses pouring in, I had to know why. So I asked a follow-up question.

Why are you still using Lodash / underscore?

if you said yes, you are using underscore / Lodash still, what features / methods, and why?

— Derick Bailey (@derickbailey)

August 31, 2016

The responses were generally categorized into two things:

  • Methods on objects, instead of just Arrays
  • Functional / composition based coding

For example, there are a lot of methods in the ES5/6 Array object that can be applied to Objects, with these libraries.

@derickbailey AFAIK, es5 map/reduce/filter only work on arrays

— Sean Corrales (@seancorrales)

August 31, 2016

@derickbailey _.pick/omit, for objects, _.isX, _.indexBy, _.sortBy, _.escape, _.debounce/throttle … I could keep going.

— Ben Vinegar (@bentlegen)

August 31, 2016

With the rise of functional programming, it’s also not surprising to see many people using these libraries in that paradigm.

@derickbailey Using Lodash/fp on almost all projects at work.

— Cyril Silverman (@CyrilSilverman)

August 31, 2016

@derickbailey also ES2015 didn’t added so much worth to me since I don’t use `this` and `prototype`-stuff. rest and spread are interesting.

— Stephan Hoyer (@cmx66)

August 31, 2016

And if you’re using these libraries already, might it be easier to use them everywhere instead of trying to remember which methods are built-in and which come from the library at this point? 

@derickbailey I obviously don’t need to use `map`, `filter` etc at this point, but I’m invested enough in the library that its easier

— Ben McCormick (@ben336)

August 31, 2016

Frankly, it seems there are some good reasons to continue using these libraries, at this point. 

Still, I had to wonder if the future of JavaScript might bring these to an end.

I mean, if these libraries are largely being replaced (at least in my use), and JavaScript is catching up to the capabilities that they provide while continuing to move forward, isn’t there a real chance that they will become obsolete?

It seemed like a possibility to me.

And I rarely use these libraries anymore, so doesn’t that show some evidence?

Well… maybe not.

John-David Dalton – the creator and maintainer of Lodash – steps in to the discussion with this:

Lodash is an active/evolving collection of 300+ modular utils that’ll continue to push beyond ES 5/6/7/.. additions.

— John-David Dalton (@jdalton)

August 31, 2016

YMNK Lodash, by way of the jQuery foundation, has TC39 representation & is involved in the evolution of JS

Categories: Blogs

Story Points Explained

Scrum Expert - Mon, 09/12/2016 - 17:50
Metrics are an important part of Agile project management approaches like Scrum. One of the most used measures to estimate the amount of work are the story points. In this small article, Pedro Gustavo Torres explains what they are, why you need them and how to use them. Pedro Gustavo Torres provides many definitions of story points. One of them is “a unitless measure of magnitude for work yet to be done, based on relative sizing.” He explains also why you should use story points based on the difference between accuracy and precision. He wrote “Accuracy and precision are not the same thing. Precision is a lot more expensive. Precision is always desired, but accuracy creates more value. However, story points provide sufficient accuracy when working in nondeterministic systems.” It is very difficult to create a precise time estimate. Story points provide an estimate that is accurate enough to define the effort that should be included in Scrum sprints. With historical data, the team can assess the relationship between time and points. However, story points cannot be related to a specific duration, but rather with a duration interval. Read the complete blog post on
Categories: Communities

GOAT 2016 Keynote Selection Survey !

Agile Ottawa - Mon, 09/12/2016 - 15:54
We have a great list of possible keynote speakers for GOAT 2016. They are all amazing in their own way and are available to attend. As you know we value your input and are making the conference bigger and better. With … Continue reading →
Categories: Communities

The 3 Pillars of Successful Products or Why Project Ara was Cancelled

Xebia Blog - Mon, 09/12/2016 - 15:37
Google managed to surprise both the market as well as the fans by cancelling the Project Ara modular phone. But from a Product Owner point of view it was no surprise. Ara phones lack a fundamental pilar that makes a product successful. Context: Ara what? In 2013 Google announced to build the Ara phone. A
Categories: Companies

Announcement: New Worldmindware Page!

Learn more about transforming people, process and culture with the Real Agility Program

BERTEIG has updated its Worldmindware page to reflect updates to our training & to highlight instructors & coaches.

Take a look. 

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Announcement: New Worldmindware Page! appeared first on Agile Advice.

Categories: Blogs

The Value of Depth and Detail

Evolving Excellence - Sun, 09/11/2016 - 18:01

details-architectureNearly three decades ago one of my first bosses pulled me aside – I forget the underlying incident except that I had somehow screwed up – and bluntly told me to “sweat the details.” I clearly remember it to this day, and it became one of the defining pieces of advice I have ever received. It was also a lesson in the power of immediate feedback versus waiting for the annual review.

I began to sweat the details, often obsessively, sometimes too much so. Just ask anyone who has traveled with me. Or lived with me.  Learning the value of details, and how to distill, evaluate and discriminate, has helped me tremendously.

Last January I told you how my annual “do something different” goal for this year is to read a work of literature from a different culture each month.  Initially this was something of a struggle for someone who typically reads Clancy-esque technothrillers and dry business tomes.  Twenty pages, if not more, just to develop a character?  You must be kidding!  Who has the patience?  But I dug in and did it.  After all, some of the most valuable goals are the ones that push you outside your comfort zone.  It’s been a very rewarding experience.

So far this year I’ve read (just as part of this goal) One Hundred Years of Solitude (Latin America), The Kite Runner (Afghanistan), Things Fall Apart (Africa), One Day in the Life of Ivan Denisovich (Russia), Men in the Sun (Palestine), The God of Small Things (India), Life and Death Are Wearing Me Out (China), and The Wind-Up Bird Chronicle (Japan).  I’m currently reading Ceremony (Native American), and next month will be Breath, Eyes, Memory (Haiti).  Any suggestions for November and December?

The Kite Runner has easily been my favorite so far, followed by Ivan Denisovich.  Ceremony has started out rather slow, but is now becoming an intriguing look at Native American society as well as the experiences of returning war veterans.  Life and Death and Wind-Up Bird were interesting immersions into Chinese and Japanese life, although keeping track of the multiple reincarnations in Life and Death (some not as humans!) became a bit difficult.

I’ve realized that what sets these works of literature apart is the depth and detail presented by the authors. Ivan Denisovich really is a couple hundred pages about just one twenty four hour day, but so engaging I couldn’t put it down! In The Kite Runner I truly felt like I was struggling to survive in Afghanistan, dealing with the consequences of war on life, livelihood, and family.  This created understanding, empathy, and compassion – exactly what I was looking for when I set this year’s goal.

Depth and details matter when telling a story.  Understanding depth and details takes either a talented author, or perhaps a trip to the gemba.  That’s one big reason why my wife and I have traveled to over 65 countries – to get the real story.  It’s scary how often that real story is at odds with sound bite-driven popular perception.

This is also evident in the lean world. We already know the value of visiting the gemba instead of making assumptions from a distant conference room.  Knowledge leaders in the field often ask themselves why lean doesn’t take root at every organization and in a sustainable fashion when there is so much evidence that it works. There’s even a lengthy survey currently circulating among such folks asking that and other similar questions.

I can tell you why: a lack of understanding of the depth and detail of lean. Instead of truly understanding what it’s about, we want to jump to the immediate benefits of 5S or value stream mapping without understanding the “why?” – and then the context of a simple tool within the overarching depth of the total lean methodology and philosophy. It’s why some of us push back on “lean six sigma” because it usually does not overtly include what I believe to be the most important aspect of lean: respect for people. Understanding respect for people, especially the roots from Toyota where it is really “respect for humanity,” is difficult.  But without it, lean simply isn’t lean.  The true power cannot be realized and sustained.

Lean is not just this or that tool.  It is an operating system framework to increase customer value by leveraging the power of people.  Understanding the depth and detail, including the historical underpinnings and how it can be uniquely applied to your specific circumstance, is critical for success.  Otherwise, even if short-term gains are realized, long-term failure is almost guaranteed.

Similar examples exist elsewhere.  Consider all the blog posts on the latest get-rich-quick or weight loss schemes that don’t convey the underlying context and circumstantial variation. How many people assume an author has professional stature just because of a superficially-reasoned argument, perhaps peppered with big words, instead of true studied knowledge and scientifically-evaluated evidence?

Tweets are 140 characters long and television and even some print news these days is reduced to sound bites.  The depth and detail has disappeared, and our opinions and decision-making are becoming very superficial – for increasingly complex and global issues.

We are losing the ability to access and process knowledge, lean and otherwise, based on  detail and depth.  How do we change that?

Perhaps we should start reading literature again to see what we’ve been missing.

Categories: Blogs

6 questions that changed my life

Scrum Breakfast - Sun, 09/11/2016 - 12:21
A few months ago I noticed that I was working like crazy and there was no end in sight. To get off this endless treadmill, I came up with my first draft of what I now call "My Personal Agility." After working with it for a few months, it all comes down to this:
  1. What really matters?
  2. Of all the things I could do, what is most important?
  3. Of all the things I could do, what really has to get done this week?
  4. What do I want to get done this week?
  5. What am I going to do today?
  6. Who can help me?
I get help from my personal agility coach who asks me these questions at regular intervals, so that I don't forget to do it. I also get some help from two information radiators: My priorities map (which I maintain on Trello) and my calendar. My priorities map helps me remember what's important and what I want to be doing. Sometimes I use my calendar for additional help on focusing during the day.

Getting my life under control meant saying 'No' to unimportant stuff so I could say yes to things that matter. Sometimes it even meant saying 'Yes' to unplanned resting, because I am not a machine, and sometimes I need to rest.

How does this work? Here is an example from my life: my kids had kind of gotten used to the fact that their requests never really got processed. I was working so hard on "important stuff" that I never had time for family stuff.

Once I decided doing things for my family really mattered, so I put it on my priorities map as point number one and labeled it with a green dot. Then every week, as I plan my week, I make sure there are a couple of green items in the list of things I want to accomplish this week. The difference was obvious immediately! Now I apply that principle at home and at work.
Here's how this works:
What really matters? These 3, maybe 4 priorities in my life guide what I say yes to. Each priority has a color code for easy identification. 
Of all the things I could do, what is most important?  I always have too much to do, so I want to focus on things that matter. If I am considering doing something that doesn't match up to something that matters, I ask myself why and whether I should do it!
Of all the things I could do, what really has to get done this week? Some things have a pressing deadline and it's important not to lose sight of them. 
What do I want to get done this week? I don't have time or energy to do everything. So of the important things and the urgent things, which ones do I think I can accomplish this week? Unchecked, the urgent tends to push out the merely important, so I sometimes I need to make space for the important. Sometimes that means that urgent stuff gets postponed or even cancelled.
What am I going to do today? This keeps me from going off on a tangent. Sometimes it's even helpful to plan my time in my calendar, for example to make room for a larger chunk of important work.
Who can help me?  At the very least, I needed someone to ask me these questions once a week or so, so I remember to answer them! Most approaches to managing your time assume that you are really by yourself. In reality, you can ask a partner, your spouse, an advisor or a professional coach to ask you the questions once a week or so. You can ask other people for help. Individual performance is important, but collaboration enables so much more!

By reflecting occasionally on what you are doing and why, you ensure that you're not just working hard, you're also doing the right thing!

Call for help: I'd like to find out if this approach could be useful in your context. If this has piqued your interest, and regardless of whether you think the answer might be yes or is probably no, I'd like to talk to you! Please contact me, and I'll set up an appointment! Thanks!

UPDATE: I have updated and will continue to update this article to make it clear. First change. The questions changed my life, the information radiators just help me do what I want! Last Update: 12-Sep-2016 at 09:12.
Categories: Blogs

Knowledge Sharing

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