Skip to content

Feed aggregator

Life Quotes That Will Change Your Life

J.D. Meier's Blog - Sat, 04/18/2015 - 08:41

Life’s better with the right words.

And life quotes can help us live better.

Life quotes are a simple way to share some of the deepest insights on the art of living, and how to live well.

While some people might look for wisdom in a bottle, or in a book, or in a guru at the top of a mountain, surprisingly, a lot of the best wisdom still exists as quotes.

The problem is they are splattered all over the Web.

The Ultimate Life Quotes Collection

My ultimate Life Quotes collection is an attempt to put the best quotes right at your fingertips.

I wanted this life quotes collection to answer everything from “What is the meaning of life?” to “How do you live the good life?” 

I also wanted this life quotes collection to dive deep into all angles of life including dealing with challenges, living with regrets, how to find your purpose, how to live with more joy, and ultimately, how to live a little better each day.

The World’s Greatest Philosophers at Your Fingertips

Did I accomplish all that?

I’m not sure.  But I gave it the old college try.

I curated quotes on life from an amazing set of people including Dr. Seuss, Tony Robbins, Gandhi, Ralph Waldo Emerson, James Dean, George Bernard Shaw, Virginia Woolf, Buddha, Lao Tzu, Lewis Carroll, Mark Twain, Confucius, Jonathan Swift, Henry David Thoreau, and more.

Yeah, it’s a pretty serious collection of life quotes.

Don’t Die with Your Music Still In You

There are many messages and big ideas among the collection of life quotes.  But perhaps one of the most important messages is from the late, great Henry David Thoreau:

“Most men lead lives of quiet desperation and go to the grave with the song still in them.” 

And, I don’t think he meant play more Guitar Hero.

If you’re waiting for your chance to rise and shine, chances come to those who take them.

Not Being Dead is Not the Same as Being Alive

E.E. Cummings reminds us that there is more to living than simply existing:

“Unbeing dead isn’t being alive.” 

And the trick is to add more life to your years, rather than just add more years to your life.

Define Yourself

Life quotes teach us that living live on your terms starts by defining yourself.  Here are big, bold words from Harvey Fierstein that remind us of just that:

“Never be bullied into silence. Never allow yourself to be made a victim. Accept no one’s definition of your life; define yourself.”

Now is a great time to re-imagine all that you’re capable of.

We Regret the Things We Didn’t Do

It’s not usually the things that we do that we regret.  It’s the things we didn’t do:

“Of all sad words of tongue or pen, the saddest are these, ‘It might have been.”  – John Greenleaf Whittier

Have you answered to your calling?

Leave the World a Better Place

One sure-fire way that many people find their path is they aim to leave the world at least a little better than they found it.

“To laugh often and much; to win the respect of intelligent people and the affection of children…to leave the world a better place…to know even one life has breathed easier because you have lived. This is to have succeeded.” -- Ralph Waldo Emerson

It’s a reminder that we can measure our life by the lives of the people we touch.

You Might Also Like

7 Habits of Highly Motivated People

10 Leadership Ideas to Improve Your Influence and Impact

Boost Your Confidence with the Right Words

The Great Inspirational Quotes Revamped

The Great Leadership Quotes Collection Revamped

Categories: Blogs

What good listeners do

Via First Among Equals, from The Trusted Advisor, what good listeners do:
  1. Probe for clarification
  2. Listen for unvoiced emotions
  3. Listen for the story
  4. Summarize well
  5. Empathize
  6. Listen for what's different, not for what's familiar
  7. Take it all seriously (don't say, "you shouldn't worry about that")
  8. Spot hidden assumptions
  9. Let the other person "get it out of his or her system"
  10. Ask, "How do you feel about that?"
  11. Keep the other person talking ("What else have you considered?")
  12. Keep asking for more detail that helps to understand
  13. Get rid of distractions while listening
  14. Focus on hearing their version first
  15. Let them tell their story their way
  16. Stand in their shoes, at least while listening
  17. Ask them how they think you might be of help
  18. Ask what they've thought of before telling them what you've thought of
  19. Look at (not stare at) the person as s/he speaks
  20. Look for "congruency" (or incongruity) between what the person says and how s/he gestures and postures
  21. Make it seem as if the other person is the only thing that matters and that they have all the time in the world
  22. Encourage by nodding head or giving a slight smile
  23. Show awareness and control of body movement (no moving around, shaking legs, fiddling with a paper clip)
Categories: Blogs

Common traits of trusted advisors

Via First Among Equals, from The Trusted Advisor, common traits of trusted advisors:
  1. Seem to understand us, effortlessly, and like us
  2. Are consistent: we can depend on them
  3. Always help us see things from fresh perspectives
  4. Don't try to force things on us
  5. Help us think things through (it's our decision)
  6. Don't substitute their judgment for ours
  7. Don't panic or get overemotional: they stay calm
  8. Help us think and separate our logic from our emotion
  9. Criticize and correct us gently, lovingly
  10. Don't pull their punches: we can rely on them to tell us the truth
  11. Are in it for the long haul: the relationship is more important than the current issue
  12. Give us reasoning (to help us think), not just their conclusions
  13. Give us options, increase our understanding of those options, give us their recommendation, and let us choose
  14. Challenge our assumptions: help us uncover the false assumptions we've been working under
  15. Make us feel comfortable and casual personally, but they take the issues seriously
  16. Act like a person, not someone in a role
  17. Are reliably on our side, and always seem to have our interests at heart
  18. Remember everything we ever said (without notes)
  19. Are always honorable: they don't gossip about others (we trust their values)
  20. Help us put our issues in context, often through the use of metaphors, stories, and anecdotes (few problems are completely unique)
  21. Have a sense of humour to diffuse our tension in tough situations
  22. Are smart sometimes in ways we're not
As someone who advises others, how well does this describe me?
Categories: Blogs

Making Sure They Do It the “Right Way”

Leading Agile - Mike Cottmeyer - Fri, 04/17/2015 - 23:21

http://pixabay.com/p-492989/

In a Certified Scrum Product Owner class I was teaching recently we got to the part about how it was up to the teams to figure out the best way to solve the business problems presented in the User Stories. We discussed the logic behind this and everyone seemed to be in agreement that it made sense that the people who do the design/coding/testing on a daily basis were the ones most familiar with the technology, the environment and the context of the needs of the end user and that it made sense for them to find the best way to meet the needs of the end user.

It was all going just fine until one of the participants in the class asked a very simple question…

“How do I know they are going to do it the right way?”

The question came from someone who was moving out of the role of lead developer into a Product Owner role.

The short answer, “You don’t. You have to trust them.”

He winced. And this is where things got twitchy. The person asking the question understood that he was supposed to trust. The problem was that understanding this intellectually, and actually doing it were two completely different things.

“Yeah, I know… but really… how do I know they’ll do it the right way?”

We talked about shaping the scope with the Acceptance Criteria, and talking with the team about any known challenges they were going to face, but that at the end of the day, it was the people doing the work that were going to have to be given the freedom to find the best way to solve the challenge placed before them. The “… but really…” question was raised a few more times and it seemed like there was a fading, desperate hope that there was going to be some secret magic answer or trick that would resolve the fear that “they” might make a mistake. Unfortunately, there is no magic answer to this. The simple fact is, “they” might solve the problem in a way that met all the needs of the User Story and it’s Acceptance Criteria but it might not be in line with how the PO would have solved the problem on his own. There is the chance that the solution the PO had in mind might have been a better way, but there is also a possibility that a team of talented, skilled individuals, working together might come up with a solution that was as good, or possibly better, than what the PO was envisioning.

If the Team delivered a solution that met the needs of the story but was somehow still not what was needed, this would become apparent during the Sprint Review meeting when the work was shown to the Stakeholders. One of the benefits of working in short iterations is that we can find problems and learn from them quickly, getting better every step of the way – both in delivering value and in working together. The longer the PO and the Team worked together, the better they get at defining and working on the User Stories.

For this particular PO, and for many people who are moving towards Agile, being open to the possibility that others may have solutions which are as good as, or better than we have isn’t an easy pill to swallow. One of the dysfunctions inherent in a traditional approach is that a command and control way of working was put in place because of the the assumption that if we don’t tell people how to do something, they’ll do it wrong.

But what if they won’t? What if they’re as smart, or smarter than us? Are we willing to let go and accept the risk of trusting again? It’s easy to say yes, but actually doing it – that is much harder. It is also one of the most challenging parts of making the switch to Agile.

Regardless of whether you are a member of the Team doing the work, someone playing the role of Product Owner or ScrumMaster, recognizing the places where the fear of trusting creeps in, observing your reaction and finding a way to take the chance of trusting people again is always hard. And it isn’t just about trusting others. We also have to learn to trust ourselves to make good choices and allow for the possibility of making mistakes and learning from them. How else are we going to get better?

https://farm6.staticflickr.com/5202/5366637592_ec37726b7b_o.jpg

Regarding the light bulb, Thomas Edison is often quoted as having said:

“I have not failed. I just found 10,000 ways that won’t work.”

If Edison had not been given the chance to find the best way to create his version of the light bulb our world would be very different than it is today.

The Scrum Guide says “Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.” This may well be true, but for Agile to sink in and really take root, those three pillars have to stand on a solid foundation of trust. What we trust in is not that people will always be “right”, but that we will run these experiments and learn every step of the way.

And who knows, there is always the chance that the Team may surprise you by coming up with a solution that is even better than the one you had in mind.

The post Making Sure They Do It the “Right Way” appeared first on LeadingAgile.

Categories: Blogs

Testomato monitors your website and alerts you if anything important breaks

TestDriven.com - Fri, 04/17/2015 - 23:00
Monitor both your staging and production environments to catch problems immediately. Instead of worrying, know when something is broken so you can fix it fast. http://www.testomato.com/
Categories: Communities

Topics for Lunch-N-Learn

Agile Complexification Inverter - Fri, 04/17/2015 - 19:57


Brainstorming a list of topics for a Scrum/Agile lunch-N-learn session.


Slicing Stories – resources to slice vertical stories of valueStory Writing techniques:  w/ Q&A based upon participants real storiesEstimation techniques:  Affinity Estimation; T-shirt sizing -> converting to numbers; Planning Poker (the rule book)Team building tools:  Infinite Loops; Helium Stick; Warp Speed;  Pair Drawing, etc.Definition of Done/Ready exerciseRelease Planning   How to derive duration with a complicated backlogAgile Library Initiation  Bring books, make the rules, get funding, 1,2,3, GO!Management 3.0 Book Club - join a group reading the best Agile book written.Making Visual Information Radiators - define Radiator/Cooler;  elements of a Scrum boardAspects of an effective Product BacklogAgile Portfolio Planning - tools and techniques; estimation, cost of delay, prioritization, deciding what NOT to doThe principle of TDD via LEGO building;  anyone can learn the power of test first developmentDoes you development rest on a SOLID foundation - an overview of the SOLID principlesCollaboration Games to understand the customer;   12 Innovation Games;  Other resourcesUser Story Maps technique to achieve higher level understanding of the backlogLaunching a Team;  what’s required, best practices, examples and techniquesTeam Practices:  a collection of quick tools to increase team work and collaboration

see also:
http://www.improvingenterprises.com/services/applied-training/lunch-n-learns/
Categories: Blogs

Saga Implementation Patterns: Singleton

Jimmy Bogard - Fri, 04/17/2015 - 17:38

NServiceBus sagas are great tools for managing asynchronous business processes. We use them all the time for dealing with long-running transactions, integration, and even places we just want to have a little more control over a process.

Occasionally we have a process where we really only need one instance of that process running at a time. In our case, it was a process to manage periodic updates from an external system. In the past, I’ve used Quartz with NServiceBus to perform job scheduling, but for processes where I want to include a little more information about what’s been processed, I can’t extend the Quartz jobs as easily as NServiceBus saga data. NServiceBus also provides a scheduler for simple jobs but they don’t have persistent data, which for a periodic process you might want to keep.

Regardless of why you’d want only one saga entity around, with a singleton saga you run into the issue of a Start message arriving more than once. You have two options here:

  1. Create a correlation ID that is well known
  2. Force a creation of only one saga at a time

I didn’t really like the first option, since it requires whomever starts to the saga to provide some bogus correlation ID, and never ever change that ID. I don’t like things that I could potentially screw up, so I prefer the second option. First, we create our saga and saga entity:

public class SingletonSaga : Saga<SingletonData>,
    IAmStartedByMessages<StartSingletonSaga>,
    IHandleTimeouts<SagaTimeout>
{
    protected override void ConfigureHowToFindSaga(
    	SagaPropertyMapper<SingletonData> mapper)
    {
    	// no-op
    }

    public void Handle(StartSingletonSaga message)
    {
        if (Data.HasStarted)
        {
            return;
        }

        Data.HasStarted = true;
        
        // Do work like request a timeout
        RequestTimeout(TimeSpan.FromSeconds(30), new SagaTimeout());
    }
    
    public void Timeout(SagaTimeout state)
    {
    	// Send message or whatever work
    }
}

Our saga entity has a property “HasStarted” that’s just used to track that we’ve already started. Our process in this case is a periodic timeout and we don’t want two sets of timeouts going. We leave the message/saga correlation piece empty, as we’re going to force NServiceBus to only ever create one saga:

public class SingletonSagaFinder
    : IFindSagas<SingletonSagaData>.Using<StartSingletonSaga>
{
    public NHibernateStorageContext StorageContext { get; set; }

    public SingletonSagaData FindBy(StartSingletonSaga message)
    {
        return StorageContext.Session
            .QueryOver<SingletonSagaData>()
            .SingleOrDefault();
    }
}

With our custom saga finder we only ever return the one saga entity from persistent storage, or nothing. This combined with our logic for not kicking off any first-time logic in our StartSingletonSaga handler ensures we only ever do the first-time logic once.

That’s it! NServiceBus sagas are handy because of their simplicity and flexibility, and implementing something a singleton saga is just about as simple as it gets.

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

Categories: Blogs

Is LeSS meer dan SAFe?

Xebia Blog - Fri, 04/17/2015 - 15:48

(Grote) Nederlandse bedrijven die op zoek zijn naar een oplossing om de voordelen die hun Agile teams brengen op te schalen, gebruiken vooral het Scaled Agile Framework (SAFe) als referentiemodel. Dit model is -ook voor managers- zeer toegankelijke opgezet en trainingen en gecertificeerde consultants zijn beschikbaar. Al in 2009 beschreven Craig Larman en Bas Vodde hun ervaringen met de toepassing van Scrum in grote organisaties (onder andere Nokia) in hun boeken 'Scaling Lean & Agile Development' en 'Practices for Scaling Lean & Agile Development'. De methode noemden ze Large Scale Scrum, afgekort LeSS.
LeSS heeft de afgelopen jaren een onopvallend bestaan geleid. Onlangs is besloten dit waardevolle gedachtengoed meer in de spotlights te zetten. Er komt in de zomer een derde boek, de site less.works is gelanceerd, er is een trainingen tournee gestart en Craig en Bas geven acte de presence op de toonaangevende conferenties. Zo zal Bas 4 juni als keynote optreden tijdens Xebicon 2015, in Amsterdam. Is LeSS meer of minder dan SAFe? Of min of meer SAFe?

Wat is LeSS?
Less is dus een methode om een grote(re) organisatie met Agile teams als basis in te richten. Zoals de naam verraadt, Scrum is daarbij het uitgangspunt. Er zijn 2 smaken: ‘gewoon’ LeSS, tot 8 teams en Less Huge, vanaf 8 teams. LeSS bouwt op verplichte regels (rules), bijvoorbeeld "An Overall Retrospective is held after the Team Retrospectives to discuss cross-team and system-wide issues, and create improvement experiments. This is attended by Product Owner, ScrumMasters, Team Representatives, and managers (if there are any).” Daarnaast kent LeSS principles (ontwerp criteria). De principes vormen het referentie raamwerk op basis waarvan je de juiste ontwerp besluiten neemt. Tenslotte zijn er de Guidelines en Experiments, de dingen die in de praktijk bij organisaties succesvol of juist niet zijn gebleken. LeSS gaat naast het basis framework verder dieper in op:

  • Structure (de organisatie structuur)
  • Management (de -veranderende- rol van management)
  • Technical Excellence (sterk gebaseerd op XP en Continuous Delivery)
  • Adoption (de transformatie naar de LeSS organisatie).

LeSS in een notendop
De basis van LeSS is dat Large Scale Scrum = Scrum! Net als SAFe wordt in LeSS gezocht naar hoe Scrum toegepast kan worden op een groep van zeg 100 man. LeSS blijft het dichtst bij Scrum: er is 1 sprint, met 1 Product Owner, 1 product backlog, 1 planning en 1 sprint review, waarin 1 product wordt gerealiseerd. Dit is dus anders dan in SAFe, waarin een opgeblazen sprint is gedefinieerd (de Product Increment). Om deze 1 sprint implementatie te kunnen waarmaken is naast een hele sterke whole product focus, bijvoorbeeld ook een technisch platform nodig, dat dit ondersteunt. Waar SAFe pragmatisch een geleidelijke invoering van Agile at Scale toestaat, is LeSS strenger in de klaar-voor-de-start eisen. Er moet een structuur worden neergezet die de cultuur van de 'contract game’ doorbreekt. De cultuur van overvragen, druk, onduidelijkheid, verrassingen, en afrekenende verantwoordelijkheid.

LeSS is meer en minder SAFe
De recente inspanning om LeSS toegankelijk te maken gaan ongetwijfeld leiden tot een sterk toenemende aandacht voor deze aansprekende benadering voor de inrichting van Agile at Scale. LeSS is anders dan SAFe, al hebben beide modellen vooral in hun inspiratiebronnen ook veel gemeen.
Beide modellen kiezen een andere insteek, bijvoorbeeld mbt:

  • hoe Scrum toe te passen op een cluster van teams
  • de benadering van de transformatie naar Agile at Scale
  • hoe oplossingen worden gebracht: SAFe geeft de oplossing, LeSS de voors en tegens van keuzes

Opvallend is verder dat SAFe (met het portfolioniveau) uitlegt hoe de verbinding tussen strategie en backlogs gelegd moet worden. LeSS besteedt daarentegen meer aandacht aan de transformatie (Adoption) en Agile op hele grote schaal (LeSS Huge).

Of een organisatie kiest voor LeSS of SAFe, zal afhangen wat het best past bij de organisatie. Past bij de veranderambitie en bij de ‘agility’ op moment van starten. Sterk ‘blauwe’ organisaties zullen kiezen voor SAFe, organisaties die een overtuigende stap richting een Agile organisatie durven te zetten, zullen eerder kiezen voor LeSS. In beide gevallen loont het om kennis te nemen van de oplossingen die de andere methode biedt.

Categories: Companies

Clickbait is evil!

Scrum Breakfast - Fri, 04/17/2015 - 09:47
Anyone who has taken one of my Scrum classes knows that I believe that multitasking is evil! I have come to realize that clickbait is evil too.

Why? For the same reason. Clickbait, like multitasking, destroys productivity.  At least for my own purposes, I have decided do something about it, and I am wondering if other people feel the same way.

What is clickbait? Let's say you an article open a reputable site, like CNN.com. See all those links on the right side, like Opinion, More Top Stories, Promoted Stories, More from CNN? That's click bait. My guess is 1/3rd of any given web pages consists of catchy headlines whose sole purpose is to get you to spend more time on their site (or maybe, to cash in on Cost-per-Click syndication schemes, to get you go to some other site). By the time you get 2/3rd down the page, 100% of the content is usually clickbait.
What is evil?What do I mean by evil? Evil things are bad for you. Like weeds in the garden or corrupt politicians, you'll never get rid of evil entirely, but if you don't keep the weeds under control, you won't have a garden any more. So we need to keep evil things in check, lest you suffer the consequences. In this case the consequences is massive amounts of wasted time (at least for me it is)!
Why is Multitasking Evil?I have long known that if you have two goals, working them in parallel slows you down. If goal A takes a month, and goal B takes a month, then if you work on A and B in parallel, it will take you at least 2 months before either goal is finished and probably longer. So focusing on one thing at a time usually gives you better results. This is why focus is a core value of Scrum. 
It turns out the situation with multitasking is much worse than I thought.
I recently attended a talk by Prof Lutz Jäncke, the neuropsychologist at the ETH, on why teenagers are the way the are. (The short answer: they are not evil, they are drawn that way. They will be people again when their brains have finished developing -- sometime around 20 years old. But I digress.)
Listening to a neuropsychologist for an hour was very challenging! My brain was very tired after his talk, but one point really stuck out:Multitasking makes you worse at multitasking!To process information effectively, we need to filter irrelevant information. By responding to every stimulus that comes in, we lose the ability to filter junk.
He also asked, have you ever gone to do something on the Internet, lost track of what you are doing and then wasted a tremendous amount of time? You bet! Every day! Why is that? Clickbait. Catchy headlines and dramatic pictures pique my curiosity to send me to the next page.
I realized this was true, and I am now trying to turn down the interruptions on my computer and other devices.Using Adblock Plus to fight clickbaitI have used ABP for a long time to block most ads. But the standard filters only target ads, not clickbait. I discovered you can not only block links, but you can block specific HTML elements. After a bit of experimenting with the block element feature, I was able to filter the clickbait sections of the news and entertainment sites I visit most. 
I was amazed at the difference in how much less clutter and fewer distractions I encountered!
Do you have this problem? Would you like to use my filter list? I don't know if it is worth packaging these filters for distribution. Or of there isn't a filter set somewhere that addresses this problem. So I have simply published this list and installation instructions on as a google doc: http://tinyurl.com/clickbait-filter. It's still pretty short, but if you send me additions, I will integrate them. 
Clickbait is evil. I believe reducing clickbait will be good for my performance, and it probably will be for yours as well. If you install it, please put out a tweet like this:
"Just installed @peterstev's clickbait filter! #clickbaitisevil! http://tinyurl.com/clickbait-filter"






Categories: Blogs

R: Think Bayes – More posterior probability calculations

Mark Needham - Thu, 04/16/2015 - 22:57

As I mentioned in a post last week I’ve been reading through Think Bayes and translating some of the examples form Python to R.

After my first post Antonios suggested a more idiomatic way of writing the function in R so I thought I’d give it a try to calculate the probability that combinations of cookies had come from each bowl.

In the simplest case we have this function which takes in the names of the bowls and the likelihood scores:

f = function(names,likelihoods) {
  # Assume each option has an equal prior
  priors = rep(1, length(names)) / length(names)
 
  # create a data frame with all info you have
  dt = data.frame(names,priors,likelihoods)
 
  # calculate posterior probabilities
  dt$post = dt$priors*dt$likelihoods / sum(dt$priors*dt$likelihoods)
 
  # specify what you want the function to return
  list(names=dt$names, priors=dt$priors, likelihoods=dt$likelihoods, posteriors=dt$post)  
}

We assume a prior probability of 0.5 for each bowl.

Given the following probabilities of of different cookies being in each bowl…

mixes = {
  'Bowl 1':dict(vanilla=0.75, chocolate=0.25),
  'Bowl 2':dict(vanilla=0.5, chocolate=0.5),
}

…we can simulate taking one vanilla cookie with the following parameters:

Likelihoods = c(0.75,0.5)
Names = c("Bowl 1", "Bowl 2")
res=f(Names,Likelihoods)
 
> res$posteriors[res$name == "Bowl 1"]
[1] 0.6
> res$posteriors[res$name == "Bowl 2"]
[1] 0.4

If we want to simulate taking 3 vanilla cookies and 1 chocolate one we’d have the following:

Likelihoods = c((0.75 ** 3) * (0.25 ** 1), (0.5 ** 3) * (0.5 ** 1))
Names = c("Bowl 1", "Bowl 2")
res=f(Names,Likelihoods)
 
> res$posteriors[res$name == "Bowl 1"]
[1] 0.627907
> res$posteriors[res$name == "Bowl 2"]
[1] 0.372093

That’s a bit clunky and the intent of ‘3 vanilla cookies and 1 chocolate’ has been lost. I decided to refactor the code to take in a vector of cookies and calculate the likelihoods internally.

First we need to create a data structure to store the mixes of cookies in each bowl that we defined above. It turns out we can do this using a nested list:

bowl1Mix = c(0.75, 0.25)
names(bowl1Mix) = c("vanilla", "chocolate")
bowl2Mix = c(0.5, 0.5)
names(bowl2Mix) = c("vanilla", "chocolate")
Mixes = list("Bowl 1" = bowl1Mix, "Bowl 2" = bowl2Mix)
 
> Mixes
$`Bowl 1`
  vanilla chocolate 
     0.75      0.25 
 
$`Bowl 2`
  vanilla chocolate 
      0.5       0.5

Now let’s tweak our function to take in observations rather than likelihoods and then calculate those likelihoods internally:

likelihoods = function(names, observations) {
  scores = c(1,1)
  names(scores) = names
 
  for(name in names) {
      for(observation in observations) {
        scores[name] = scores[name] *  mixes[[name]][observation]      
      }
    }  
  return(scores)
}
 
f = function(names,mixes,observations) {
  # Assume each option has an equal prior
  priors = rep(1, length(names)) / length(names)
 
  # create a data frame with all info you have
  dt = data.frame(names,priors)
 
  dt$likelihoods = likelihoods(Names, Observations)
 
  # calculate posterior probabilities
  dt$post = dt$priors*dt$likelihoods / sum(dt$priors*dt$likelihoods)
 
  # specify what you want the function to return
  list(names=dt$names, priors=dt$priors, likelihoods=dt$likelihoods, posteriors=dt$post)  
}

And if we call that function:

Names = c("Bowl 1", "Bowl 2")
 
bowl1Mix = c(0.75, 0.25)
names(bowl1Mix) = c("vanilla", "chocolate")
bowl2Mix = c(0.5, 0.5)
names(bowl2Mix) = c("vanilla", "chocolate")
Mixes = list("Bowl 1" = bowl1Mix, "Bowl 2" = bowl2Mix)
Mixes
 
Observations = c("vanilla", "vanilla", "vanilla", "chocolate")
 
res=f(Names,Mixes,Observations)
 
> res$posteriors[res$names == "Bowl 1"]
[1] 0.627907
 
> res$posteriors[res$names == "Bowl 2"]
[1] 0.372093

Exactly the same result as before! #win

Categories: Blogs

Join Me in Australia in June!

Agile Product Owner - Thu, 04/16/2015 - 17:56

Hi,

This June, I’ll be busy in Australia presenting a SAFe SPC certification class, and speaking at Agile Australia as an invited spearker where I’ll lead workshops, and present “Nine Immutable Principles of Lean-Agile Development.”

Agile Australia 2015

Invited Speaker Track: Nine Immutable Principles of Lean-Agile Development

Half-day Workshops: Foundations of the Scaled Agile Framework

Sydney 16 June (two workshops); Melbourne 19 June 2015 (AM only).

In this half-day workshop, you’ll learn the foundations of the Scaled Agile Framework (SAFe), its values and underlying principles of Agile, Lean and Product Development Flow. This course will enable you to leave with an understanding of how the principles and practices of SAFe support large scale Agile Software Programs,  Lean Systems Engineering and Agile Portfolio Management. You’ll also learn about effective strategies for implementing SAFe, including the critical role that Leadership plays. These rare half-day workshops provide a personal setting that helps assure effective knowledge exchange.

See detailed descriptions and register at www.agileaustralia.com.au/2015/workshops. Earlybird registration closes on Friday 24 April 2015, and you can get a further discount using this promo code, AA15-SFND

SAFe Program Consultant Certification June 22-25, 2015

Logo_ContextMatters_DirectoryThis is the official 4-day SAFe Certification Program which results in the SAFe Program Consultant (SPC) Certification. I don’t get a chance to deliver this workshop myself that often anymore, especially in Asia-Pacific, so I encourage you to attend this unique event. We’ll be working with our local Gold Partners Context Matters, and you can contact Mark or Em for more information. Early bird pricing is available until 22, May 2015.

I hope to see you in Australia!

—Dean

Categories: Blogs

How We Can Inspire a Million Children to Become Engineers

Agile Management Blog - VersionOne - Thu, 04/16/2015 - 14:37

CoderDojo

We can all agree that inspiring children to become engineers and scientists is of utter importance. However making a difference on a local level seems intimidating. But it doesn’t have to be so difficult.

Learn how you can help us inspire a million children to become engineers by providing just a few hours a month and a safe, collaborative meeting space.

The Challenge

A few years ago Robert Holler, the president and CEO of VersionOne, challenged VersionOne employees to come up with an idea that would help children in our local community learn about programming and technology. This seemed like an exciting, though daunting, community service project.

At VersionOne we feel it is an important responsibility to help the community. That doesn’t mean just the agile community, but also the local community. In fact, Gartner recently recognized our strong community presence in the Magic Quadrant for Application Development Lifecycle Management report.

Typically when we do local community projects they are hosted by charities that manage projects. This project, on the other hand, would be completely managed by VersionOne employees. At first, this seemed like it might take a lot more time and effort than any of us really had. Nonetheless, we were very excited to try to make it work.event_258537472

There were a lot of ideas that would need varying degrees of resources, but after a little research we discovered the global CoderDojo movement. It was a movement started in Ireland in 2011 by an eighteen-year-old student and a serial entrepreneur. They developed a vision for creating a safe and collaborative environment in which experienced adult mentors help students who want to learn about technology and programming. Their model was fairly lean, making it easy to launch. Parents bring their kids and their own laptops, so we just needed space and mentors to get started.

Since VersionOne is an agile lifecycle management company, we were attracted to the lean nature of this program. Soon after, CoderDojo Ponce Springs was born!

How It Works

The way it works is that parents bring their kids, ages 7 through 17, with laptops in hand to a meeting place. (In our case, we also have a limited number of laptops that have been donated by VersionOne for kids who don’t have a laptop). Volunteers help the students learn a programming language or other creative tools.

event_258537462

There are tons of great free resources like TeachingKidsProgramming.com, Khan Academy, Codecademy, CODE.org, Scratch, Blockly Games, and more. This makes it less burdensome for new volunteers to help because they don’t need to spend hours and hours creating their own resources.

However, a number of our volunteers have devoted additional time to creating step-by-step tutorials and interactive tools tailored to the needs of students who have been through the beginner materials online and want to more challenging things like building plugins for Minecraft or learning about building HTML5 JavaScript games.

Student-Driven Learning

We should stress, however, that the bulk of the work is on the students themselves! Mentors are there to assist and inspire, but not to provide long, drawn-out lectures. Students rapidly get hands on with the technologies and help each other learn. It’s a theme that’s woven throughout the CoderDojo movement. One of its own mentors is Sugata Mitra, who has conducted some amazing experiments in child-driven learning. Check out his TED talks to see what he discovered about the innate curiosity and capacity for learning and teaching that children possess.

Want to Start Your Own CoderDojo?

We share code and resources in GitHub in this open source and forkable CoderDojoPonceSprings repository. Feel free to create a copy of it and start one in your own community! Our Dojos take place in downtown Atlanta and in Alpharetta, Georgia, but one of our volunteers cloned our content and started a brand new CoderDojo in Henry County, about 30 minutes south of Atlanta.

Impact

It has been exciting to see the program still going strong for more than two years. The majority of the students are returning students, a good indication of the value they are getting from the program. In fact, many of the students have been participating for the entire program, and are becoming quite advanced. These are the students who have encouraging parents and peers outside of the Dojo as well, because it takes more just attending a Dojo to become really advanced.

What a CoderDojo is best at is providing the safe, collaborative environment for students who are ready and willing to learn to meet other enthusiastic peers with whom they can collaborate and increase their knowledge. Research has shown that when someone is learning something new, they often learn best from peers who are just slightly ahead. A CoderDojo also provides students who want to help others an opportunity to start giving back immediately. In one particular case, we had a student serve as a mentor to much younger students. He is thirteen and participated in a special event with students from an Atlanta elementary school.

A Million Children

Making a difference in the world can seem like a daunting feat, but the greatest lesson that I think has come out of our CoderDojo project is that by simply providing some space and time, we can inspire the next generation to get excited about programming and technology.

We probably have 300 different children come to our program each year. Over the next five years we hope to inspire 1,500 children in our program. If each of the three chapters that launched after ours has the same results, together we will inspire 4,500 children. And if 223 companies are willing to join us, we all can inspire 1,000,000 children over the next five years.

Volunteers in our Dojo are currently collaborating on tools and content to make starting a new CoderDojo even easier, if you’re interested to learn more or start your own CoderDojo, email us at coderdojo@versionone.com.

So what do you have to say, will you help us inspire the next generation of software programmers?

Categories: Companies

Experimenting with Swift and UIStoryboardSegues

Xebia Blog - Wed, 04/15/2015 - 22:58

Lately I've been experimenting a lot with doing things differently in Swift. I'm still trying to find best practices and discover completely new ways of doing things. One example of this is passing objects from one view controller to another through a segue in a single line of code, which I will cover in this post.

Imagine two view controllers, a BookViewController and an AuthorViewController. Both are in the same storyboard and the BookViewController has a button that pushes the AuthorViewController on the navigation controller through a segue. To know which author we need to show on the AuthorViewController we need to pass an author object from the BookViewController to the AuthorViewController. The traditional way of doing this is giving the segue an identifier and then setting the object:

class BookViewController: UIViewController {

    var book: Book!

    override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
        if segue.identifier == "ShowAuthor" {
            let authorViewController = segue.destinationViewController as! AuthorViewController
            authorViewController.author = book.author
        }
    }
}

class AuthorViewController: UIViewController {

    var author: Author!
}

And in case we would use a modal segue that shows a AuthorViewController embedded in a navigation controller, the code would be slightly more complex:

if segue.identifier == "ShowAuthor" {
  let authorViewController = (segue.destinationViewController as! UINavigationController).viewControllers[0] as! AuthorViewController
  authorViewController.author = book.author
}

Now let's see how we can add an extension to UIStoryboardSegue that makes this a bit easier and works the same for both scenarios. Instead of checking the segue identifier we will just check on the type of the destination view controller. We assume that based on the type the same object is passed on, even when there are multiple segues going to that type.

extension UIStoryboardSegue {

    func destinationViewControllerAs<T>(cl: T.Type) -> T? {
        return destinationViewController as? T ?? (destinationViewController as? UINavigationController)?.viewControllers[0] as? T
    }
}

What we've done here is add the method destinationViewControllerAs to UIStoryboardSegue that checks if the destinationViewController is of the generic type T. If it's not, it will check if the destinationViewController is a navigation controller and if it's first view controller is of type T. If it finds either one, it will return that instance of T. Since it can also be nil, the return type is an optional T.

It's now incredibly simple to pass on our author object to the AuthorViewController:

override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
  segue.destinationViewControllerAs(AuthorViewController.self)?.author = book.author
}

No need to check any identifiers anymore and less code. Now I'm not saying that this is the best way to do it or that it's even better than the traditional way of doing things. But it does show that Swift offers us new ways of doing things and it's worth to experiment to find best practices.

The source code of the samples and extension is available on https://github.com/lammertw/StoryboardSegueExtension.

Categories: Companies

11 years at ThoughtWorks

thekua.com@work - Wed, 04/15/2015 - 22:45

I had planned to write a 10 years at ThoughtWorks post but was busy on a sabbatical learning a real language (German!) This year, I decided to get around to writing an anniversary post. One of the current impressive employee benefits for long-time employees is a 12-week paid break (it’s mandatory law in Australia but not true around the world).

When I think about my time here at ThoughtWorks, I can’t believe that I have been here so long. I still remember, after graduating from University, thinking how unlikely I would stay with a company for more than two years because I wanted to learn, change and grow. I thought that would be difficult in a permanent position in any other company. I wanted to stay in the zone but also find an opportunity to do interesting work. Consulting proved to be a good middle ground for what I was looking for.

What a ride it has been. Oh, and it’s still going, too :)

Facts

Like most companies, ThoughtWorks has changed and evolved over time.

  • When I started, we had (I’m guessing) about 10 offices in four countries. As of this post, we have 30 offices in 12 countries (Australia, Brazil, Canada, China, Ecuador, Germany, India, Singapore, South Africa, Uganda, the United Kingdom, and the United States) in some places I would never have guessed we would have had offices.
  • When I started, we had maybe 500 employees worldwide. We now have around between 2500-3000 people.
  • When I started, we were pretty much a consulting firm doing software development projects. Since then we now have a product division, a highly integrated UX capability, and are influencing companies at the CxO level which means a different type of consulting (whilst still keeping to our core offering of delivering effective software solutions).

We don’t always get things right, but I do see ThoughtWorks takes risks. In doing so, that means trying things and being prepared to fail or succeed. Although we have grown, I have found it interesting to see how our culture remains, in some ways very consistent, but adapts to the local market cultures and constraints of where we are operating. When I have visited our Brazilian offices, I felt like it was TW but with a Brazilian flavour, likewise when I visit our German offices.

Observations

I find it constantly interesting talking to alumni or people who have never worked for ThoughtWorks to see what their perceptions are. With some alumni, they have a very fixed perception of what the company is like (based on their time with the company) and it’s interesting to contrast that view with my own, given that the company constantly changes.

We are still (at least here in the UK) mostly a consulting firm, and so some of the normal challenges with running a consulting business still apply, both from an operational perspective, and being a consultant out on the field. Working on client site often means travel, and still affected by the ebbs and flows of customer demand around client budgeting cycles.

Based on my own personal observations (YMMV) we, as a company, have got a lot better about leadership development and support (although there is always opportunity to improve). I also find that we tend, on average, to get more aligned clients and have opportunities to have a greater impact. We have become better at expressing our values (The Three Pillars) and finding clients where we can help them and they are ready for that help.

It is always hard to see colleagues move on as it means building new relationships but that is always a reality in all firms, and occurs often even more so in consulting firms. After coming back from sabbatical I had to deal with quite a bit of change. Our office had moved, a significant part of our management team had changed, and of course there were lots of new colleagues who I hadn’t met. At the same time, I was surprised to see how many long-time employees (and not just operational people) were still around and it was very comforting to reconnect with them and renew those relationships.

Highlights

I’ve been particularly proud of some of the impact and some of the opportunities I have had. Some of my personal highlights include:

  • Being the keynote speaker for the 2000-attendee Agile Brazil conference.
  • Publishing my first book, The Retrospective Handbook, a book that makes the agile retrospective practice even more effective.
  • Publishing my second book, Talking with Tech Leads, a book that collects the experiences of Tech Leads around the world aimed at helping new or existing Tech Leads improve their skills.
  • Developing a skills training course for Tech Leads that we run internally. It’s a unique experiential course aimed at raising awareness of and developing the skills developers need when they play the Architect or Tech Lead roles. I may even have an opportunity of running it externally this year.
  • Being considered a role model for how ThoughtWorks employees can have impact on both clients, the industry and within our own company.
Categories: Blogs

Laloux Cultural Model and Agile Adoption

Agile For All - Bob Hartman - Wed, 04/15/2015 - 19:10
Laloux and Agile Adoption My Story

I had invested years of my life in a ground up, large-scale agile adoption. The early years of the adoption seemed to go at breakneck speed. Teams were adopting scrum with great success. People were feeling more engaged, products were getting better, and the company was benefiting. And then it felt like we hit a wall. Despite what felt to me like a groundswell of support from teams, managers, and directors, we were struggling to make the leap to real organizational agility.

The Breakthrough

While reviewing a draft of a good friend’s upcoming book, a single reference leaped off the page:

“There is … evidence that the developmental stage of the CEO determines the success of large-scale transformation programs.” (Tolbert, cited by Laloux, 2014)

I immediately bought and read Frederic Laloux’s book Reinventing Organizations, which provides a comprehensive overview of how humans have organized in groups over the centuries. The prevailing perspective today (what Laloux labels “orange”) seemed to describe my organization in an almost clairvoyant way. It helped me make sense of what my organization valued the most, how I could continue to be effective in my role as agile transformation leader, and what was likely possible given our cultural values. Keep reading to learn more…

Laloux’s Culture Model

I created the following video overview of Laloux’s cultural model and how it applies to Agile adoption in various types of organizations. It’s kind of a whirlwind tour, but I wanted to cover the basics in as succinct a way as possible. Feel free to pause and ponder as you digest the information.

 

 

The Rest of the Story…

Did one of the descriptions/colors stick out to you as the prevailing perspective at your organization? How about for you personally? My story takes an interesting twist after reading Laloux’s book. The prevailing perspective at the executive level seemed firmly rooted in Orange. I felt like I was somewhere between green and teal, personally. The difference in what I valued the most, and what the organization valued most, helped me understand why I had been so frustrated with the wall it seemed we had reached at the organizational level.

For me, it seemed I had three options:

  1. Acknowledge the value in an Orange perspective (there is value in every perspective), and work hard to help my organization be a shining example of Orange at its most vibrant.
  2. Seek out leaders with a Green perspective and work with them to try to expand the influence of Green values in the organization.
  3. Leave the organization and seek out Green or Teal organizations where I could grow personally at a faster pace.

Option one had been my journey for the first several years of my work leading our agile transformation. Option two had been my approach for the previous 18 months, but seemed to stall out when we needed executive level support for the types of changes required for a vertical transformation from Orange to Green. For option two, it felt like a waiting game – I could work with Green leaders in the hopes that at some point, the current CEO would either evolve personally, or, as happens frequently in large organizations, a new CEO would eventually come along, and all of the Green level cultural work would be unlocked and begin to flourish. This felt like a crapshoot as to what perspective that new CEO might have, and how long it might be before such a change might occur.

This left me with Option three, and that’s the option I took. While I think I could have provided value helping the organization be the best version of Orange it could, for my own personal growth, I really wanted to advance what’s possible and see how I can add value in a Green or Teal organization. I joined Agile for All knowing that they had been doing some really cool work with organizations adopting a Green/Teal set of practices, and I’m excited to see where we can go with such an approach.

So Now What?

First of all, definitely check out Laloux’s book. He provides fantastic details of how Teal organizations do awesome things.

If you are in a predominantly Amber or Orange organization, we’ve been there! We’ve seen Agile help these organizations get better at what they care about most, be that stability and predictability (Amber), or innovation and competitive advantage (Orange). An Agile mindset and practices will help achieve awesome results, and in a way that is more engaging and fulfilling for the people doing the work.

If you are in a predominantly Green or even a Teal organization, or one interested in moving in that direction, please get in touch! We’d love to hear about how it’s working for you. Whether we can help you out or not, we want to learn more about and help connect organizations taking this approach.

No matter your organization’s primary perspective, if you are interested in learning more about deep, long-lasting organizational transformation then let’s talk! Email me at peter.green@agileforall.com or just respond to this blog post.

If you think others would be interested in this topic, please share it using one or more of the buttons below.

The post Laloux Cultural Model and Agile Adoption appeared first on Agile For All.

Categories: Blogs

Summary of User Stories: The Three “C”s and INVEST

Learn more about our Scrum and Agile training sessions on WorldMindware.comUser Stories Learning Objectives

Becoming familiar with the “User Story” approach to formulating Product Backlog Items and how it can be implemented to improve the communication of user value and the overall quality of the product by facilitating a user-centric approach to development.

Consider the following

User stories trace their origins to eXtreme Programming, another Agile method with many similarities to Scrum. Scrum teams often employ aspects of eXtreme Programming, including user stories as well as engineering practices such as refactoring, test-driven development (TDD) and pair programming to name a few. In future modules of this program, you will have the opportunity to become familiar enough with some of these practices in order to understand their importance in delivering quality products and how you can encourage your team to develop them. For now, we will concentrate on the capability of writing good user stories.

The Three ‘C’si

A User Story has three primary components, each of which begin with the letter ‘C':

Card

  • The Card, or written text of the User Story is best understood as an invitation to conversation. This is an important concept, as it fosters the understanding that in Scrum, you don’t have to have of the Product Backlog Items written out perfectly “up front”, before you bring them to the team. It acknowledges that the customer and the team will be discovering the underlying business/system needed as they are working on it. This discovery occurs through conversation and collaboration around user stories.
  • The Card is usually follows the format similar to the below

As a <user role> of the product,

I can <action>

So that <benefit>.

  • In other words, the written text of the story, the invitation to a conversation, must address the “who”, “what” and “why” of the story.
  • Note that there are two schools of thought on who the <benefit> should be for. Interactive design specialists (like Alan Cooper) tell us that everything needs to be geared towards not only the user but a user Persona with a name, photo, bio, etc. Other experts who are more focused on the testability of the business solution (like Gojko Adzic) say that the benefit should directly address an explicit business goal. Imagine if you could do both at once! You can, and this will be discussed further in more advanced modules.

Conversation

  • The collaborative conversation facilitated by the Product Owner which involves all stakeholders and the team.
  • As much as possible, this is an in-person conversation.
  • The conversation is where the real value of the story lies and the written Card should be adjusted to reflect the current shared understanding of this conversation.
  • This conversation is mostly verbal but most often supported by documentation and ideally automated tests of various sorts (e.g. Acceptance Tests).

Confirmation

  • The Product Owner must confirm that the story is complete before it can be considered “done”
  • The team and the Product Owner check the “doneness” of each story in light of the Team’s current definition of “done”
  • Specific acceptance criteria that is different from the current definition of “done” can be established for individual stories, but the current criteria must be well understood and agreed to by the Team.  All associated acceptance tests should be in a passing state.
INVESTii

The test for determining whether or not a story is well understood and ready for the team to begin working on it is the INVEST acronym:

I – Independent

  • The solution can be implemented by the team independently of other stories.  The team should be expected to break technical dependencies as often as possible – this may take some creative thinking and problem solving as well as the Agile technical practices such as refactoring.

N – Negotiable

  • The scope of work should have some flex and not be pinned down like a traditional requirements specification.  As well, the solution for the story is not prescribed by the story and is open to discussion and collaboration, with the final decision for technical implementation being reserved for the Development Team.

V – Valuable

  • The business value of the story, the “why”, should be clearly understood by all. Note that the “why” does not necessarily need to be from the perspective of the user. “Why” can address a business need of the customer without necessarily providing a direct, valuable result to the end user. All stories should be connected to clear business goals.  This does not mean that a single user story needs to be a marketable feature on its own.

E – Estimable

  • The team should understand the story well enough to be able estimate the complexity of the work and the effort required to deliver the story as a potentially shippable increment of functionality.  This does not mean that the team needs to understand all the details of implementation in order to estimate the user story.

S – Small

  • The item should be small enough that the team can deliver a potentially shippable increment of functionality within a single Sprint. In fact, this should be considered as the maximum size allowable for any Product Backlog Item as it gets close to the top of the Product Backlog.  This is part of the concept of Product Backlog refinement that is an ongoing aspect of the work of the Scrum Team.

T – Testable

  • Everyone should understand and agree on how the completion of the story will be verified. The definition of “done” is one way of establishing this. If everyone agrees that the story can be implemented in a way that satisfies the current definition of “done” in a single Sprint and this definition of “done” includes some kind of user acceptance test, then the story can be considered testable.

Note: The INVEST criteria can be applied to any Product Backlog Item, even those that aren’t written as User Stories.

Splitting Stories:

Sometimes a user story is too big to fit into a Sprint. Some ways of splitting a story include:

  • Split by process step
  • Split by I/O channel
  • Split by user options
  • Split by role/persona
  • Split by data range

WARNING: Do not split stories by system, component, architectural layer or development process as this will conflict with the teams definition of “done” and undermine the ability of the team to deliver potentially shippable software every Sprint.

Personas

Like User Stories, Personas are a tool for interactive design. The purpose of personas is to develop a precise description of our user and so that we can develop stories that describe what he wishes to accomplish. In other words, a persona is a much more developed and specific “who” for our stories. The more specific we make our personas, the more effective they are as design tools.iii

Each of our fictional but specific users should have the following information:

  • Name
  • Occupation
  • Relationship to product
  • Interest & personality
  • Photo

Only one persona should be the primary persona and we should always build for the primary persona. User story cards using personas replace the user role with the persona:

<persona>

can <action>

so that <benefit>.

 

i The Card, Conversation, Confirmation model was first proposed by Ron Jeffries in 2001.

ii INVEST in Good Stories, and SMART Tasks. Bill Wake. http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

iii The Inmates are Running the Asylum. Alan Cooper. Sams Publishing. 1999. pp. 123-128.

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

Coaching intervention during a team conflict

Agile World - Venkatesh Krishnamurthy - Wed, 04/15/2015 - 14:42

Every team goes through some stages of conflict before they stabilize. Leaders need to be conscious of intervening during such conflicts.  The knee-jerk reaction of a typical leader observing a conflict is to jump immediately to “fix” the problem. It is highly recommended that they avoid it and take a step back to monitor the situation first.

The leaders need to find the appropriate time and context to intervene for coaching. Here are some examples and contexts.

1. Self-organizing teams are in the process of learning. They are trying to check the boundaries and positioning themselves in the team. Conflicts in such situations are imminent. The leader or a coach assigned to the team should avoid intervening in such contexts. 

image These teams are like butterflies emerging from pupa. Yes, there is a bit of process, pain and time involved to emerge out of pupa, and one needs a bit of patience. Trying to expedite the process could actually kill the butterfly. 

2. Research suggests that creative and innovative work actually needs healthy debate and conflict. Intervention is needed to help the in understanding the differences. There are many times a person or a small group within a large group might be thinking tangentially. This could lead to conflicts and it does not mean that there is anything wrong here. In fact, such conflicts avoid groupthink.

For example, an engineer embedded in a marketing team obviously think differently. The engineer could be considered as a trouble maker as he/she is different than the rest of the marketing team. In contexts like this, the leadership or coach intervention is essential to assist the group.

As a leader one needs to drill down a little bit, get rid of the noise and study the type of work before intervening. The diversity of the team needs to be taken into account while dealing with a creative team as well.

image

3. If the team is working on a routine and repetitive kind of work, coaching intervention trying to facilitate discussions could backfire. Instead, a root-cause analysis with a management intervention is critical for smooth functioning.  

To conclude, if you see or hear a conflict, don’t jump to fix the problem. Try to understand the context first. Many a times, the conflict is actually good for the team, and the organization in the long run.

Categories: Blogs

Slashdot quote of the year

Indefinite Articles - John Brothers - Wed, 04/15/2015 - 13:46

In the context of this story about Neal Stephenson’s novel Seveneves (neither block-quote nor italicized follow-up are mine):

 

Authors improve with age?

Some do. For example, in many years time, Stephenie Meyer will be dead.

 

Golf clap

Categories: Blogs

April Newsletter: Measuring Predictability, Lean Decision Filter, Flow-driven Product Development

Here’s the April 2015 edition of the LeanKit monthly newsletter. Make sure you catch the next issue in your inbox and subscribe today. Kanban for DevOps: 3 Reasons IT Ops Uses Lean Flow (part 3 of 3) In the final post of this three-part series, Dominica DeGrandis explores why product support needs a voice in product development […]

The post April Newsletter: Measuring Predictability, Lean Decision Filter, Flow-driven Product Development appeared first on Blog | LeanKit.

Categories: Companies

day in, day out

Derick Bailey - new ThoughtStream - Wed, 04/15/2015 - 12:00

You know what I really wanted to do, today? Work on SignalLeaf. It’s not that it *needs* any work right now… it’s been running in auto-pilot for several months now, while I’ve had other more urgent things to take care of. But I *wanted* to work on SignalLeaf.   And yet, I didn’t get too. There were too many other things that were more urgent.

rolling-rock-uphill

Motivation Can Be Distraction

People talk about motivation all the time – myself included. We talk about how rare it is and how you should work your butt off when you find yourself motivated.

But this isn’t usually where I find myself, honestly.

I usually find find motivation for the thing that I’m not working on,  instead. Frankly, it’s easier to be motivated to work on the thing that I’m not doing. I don’t have to actually do the work. I can just sit back, think about how great it’s going to be when I’m done and get excited about it. That’s motivation for me to work on it.

But when I get down to actually doing it – to the point where I have to put in the time, the effort and figure out how to make it work… well, the motivation to do the work is usually fleeting for me. I would rather think about something else that I want to do instead.

The Daily Grind

Motivation is especially difficult when I’ve been on a project for a long time – when the work is constant, and never ending.

When I look at WatchMeCode screencasts, for example, I see nothing but an endless amount of work. I see endless hours spent trying to figure out what would make a good screencast. I see the practice, the setup, the additional practice to make sure I understand what I want to say. I see the more than 100 episodes of video content that I have produces in the last 4 years and the effort that has gone in to it.

And as predictable as the changing seasons, I don’t want to work on screencasts anymore.

But I do it anyways. I record yet another screencast. I put my thoughts and understanding in to something that will hopefully help other people learn.

It becomes a grind… a never ending effort to push an ever growing ball up a hill.

A Tipping Point?

They say it gets easier after some time – that there will be some magical tipping point where the ball starts to roll downhill.

Maybe that’s true. Maybe there will be some point in the future at which WatchMeCode will mostly take care of itself and I won’t have to worry about it.

But not everything will have that tipping point.

Just Showing Up

Sometimes the work we do is never ending. Sometimes the best we can do it just show up to work, and slog through it. That in itself can be a victory on it’s own.

There isn’t always a light at the end of the tunnel. We hope there is, or we eventually figure out that there isn’t and we move on to another tunnel.

For me, I’m going through yet another round of wondering if another tunnel is the better option. But then I think about how little effort WatchMeCode takes, in comparison to other things I could be doing. I compare the income from screencasts vs the income from the other products and services I have, and there’s no way I can leave it – not yet, at least.

In To The Future

There’s no way I can know what the future will bring for me. I don’t have any plans on leaving my screencasting efforts behind. I need the income, and the work is relatively easy compared to other sources of income that I have.

I may look back on this time, in a month or two, and wonder what I was complaining about. I probably will do that. It’s just another cycle of me doubting what I’m doing and coming to terms with the endless grind that is screencasting.

I Do What I Have To Do

I really don’t want to work on screencasts right now. But I need to. I have to keep the content flowing so my income continues. So, I clock in. I prepare, I record and I release another episode on the weekly schedule that I set for myself. Some times it seems worth it. Sometimes I get tired of it, like today.

I grind the wheel of another day, hoping I can build up enough of a buffer to give myself a few weeks off. I’d like to find that tipping point, but I don’t see it yet. So I grind on.

Day, in. Day out. Week after week. Month after month. Cause sometimes, that’s what you have to do.

– Derick

Categories: Blogs

Knowledge Sharing


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