We’re excited to announce that VersionOne has been named as one of the Best Places to Work by the Atlanta Business Chronicle. The Best Places to Work 2016 awards recognize 100 of the top companies in Metro Atlanta. The award … Continue reading →
The post VersionOne Named One of the Best Places to Work by the Atlanta Business Chronicle appeared first on The Agile Management Blog.
Alexey Krivitsky recently posted a presentation on his blog, agiletrainings.eu, addressing the issue of so-called-agile tools, specifically Jira.
Here is a link to his presentation.
The movie images he chose gave me a chuckle and his points really hit home.
He offers 4 points to what he calls a “Jira Rehab Program” and I found the points interesting.
Take a look. See what you think.
Share your comments on your experience with agile tools here.
Have you had success with Jira or would you rather see it disposed of?
And check out Mishkin’s recent article on the ideal electronic Agile tool.
Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
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.
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!
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.
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]]) 2.1094237467877998e-15
What about if we make a completely wrong prediction?
>>> log_loss(actual_labels, [[0, 0, 1], [1, 0, 0], [0, 1, 0]]) 34.538776394910684
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) 0.0 >>> math.exp(0) 1.0
# every prediction completely wrong >>> math.log(0.000000001) -20.72326583694641 >>> math.exp(-20.72326583694641) 1.0000000000000007e-09
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]]) 0.363548039673
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]]) 0.363548039673
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) 0.6952053289772744
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]]) 0.299001158669 >>> math.exp(-0.299001158669) 0.741558550213609
74% accuracy overall, sounds about right!
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!
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??’”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.
Shara Senderoff, CEO of Intern Sushi, in this Forbes article
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?
Agile 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?Conclusion
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
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.
“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.
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.
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.
- Sponsored: 64% off Code Black Drone with HD Camera
Our #1 Best-Selling Drone--Meet the Dark Night of the Sky!
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?
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.
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)
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)
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)
@derickbailey _.pick/omit, _.map for objects, _.isX, _.indexBy, _.sortBy, _.escape, _.debounce/throttle … I could keep going.
— Ben Vinegar (@bentlegen)
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)
@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)
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)
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. https://t.co/AvOLZXt5Wg
— John-David Dalton (@jdalton)
YMNK Lodash, by way of the jQuery foundation, has TC39 representation & is involved in the evolution of JS