Skip to content

Feed aggregator

R: Replacing for loops with data frames

Mark Needham - Thu, 04/23/2015 - 00:18

In my last blog post I showed how to derive posterior probabilities for the Think Bayes dice problem:

Suppose I have a box of dice that contains a 4-sided die, a 6-sided die, an 8-sided die, a 12-sided die, and a 20-sided die. If you have ever played Dungeons & Dragons, you know what I am talking about.

Suppose I select a die from the box at random, roll it, and get a 6.
What is the probability that I rolled each die?

To recap, this was my final solution:

likelihoods = function(names, observations) {
  scores = rep(1.0 / length(names), length(names))  
  names(scores) = names
 
  for(name in names) {
      for(observation in observations) {
        if(name < observation) {
          scores[paste(name)]  = 0
        } else {
          scores[paste(name)] = scores[paste(name)] *  (1.0 / name)
        }        
      }
    }  
  return(scores)
}
 
dice = c(4,6,8,12,20)
l1 = likelihoods(dice, c(6))
 
> l1 / sum(l1)
        4         6         8        12        20 
0.0000000 0.3921569 0.2941176 0.1960784 0.1176471

Although it works we have nested for loops which aren’t very idiomatic R so let’s try and get rid of them.

The first thing we want to do is return a data frame rather than a vector so we tweak the first two lines to read like this:

scores = rep(1.0 / length(names), length(names))  
df = data.frame(score = scores, name = names)

Next we can get rid of the inner for loop and replace it with a call to ifelse wrapped inside a dplyr mutate call:

library(dplyr)
likelihoods2 = function(names, observations) {
  scores = rep(1.0 / length(names), length(names))  
  df = data.frame(score = scores, name = names)
 
  for(observation in observations) {
    df = df %>% mutate(score = ifelse(name < observation, 0, score * (1.0 / name)) )
  }
 
  return(df)
}
 
dice = c(4,6,8,12,20)
l1 = likelihoods2(dice, c(6))
 
> l1
       score name
1 0.00000000    4
2 0.03333333    6
3 0.02500000    8
4 0.01666667   12
5 0.01000000   20

Finally we’ll tidy up the scores so they’re relatively weighted against each other:

likelihoods2 = function(names, observations) {
  scores = rep(1.0 / length(names), length(names))  
  df = data.frame(score = scores, name = names)
 
  for(observation in observations) {
    df = df %>% mutate(score = ifelse(name < observation, 0, score * (1.0 / name)) )
  }
 
  return(df %>% mutate(weighted = score / sum(score)) %>% select(name, weighted))
}
 
dice = c(4,6,8,12,20)
l1 = likelihoods2(dice, c(6))
 
> l1
  name  weighted
1    4 0.0000000
2    6 0.3921569
3    8 0.2941176
4   12 0.1960784
5   20 0.1176471

Now we’re down to just the one for loop. Getting rid of that one is a bit trickier. First we’ll create a data frame which contains a row for every (observation, dice) pair, simulating the nested for loops:

likelihoods3 = function(names, observations) {
  l = list(observation = observations, roll = names)
  obsDf = do.call(expand.grid,l) %>% 
    mutate(likelihood = 1.0 / roll, 
           score = ifelse(roll < observation, 0, likelihood))   
 
  return(obsDf)
}
 
dice = c(4,6,8,12,20)
l1 = likelihoods3(dice, c(6))
 
> l1
  observation roll likelihood      score
1           6    4 0.25000000 0.00000000
2           6    6 0.16666667 0.16666667
3           6    8 0.12500000 0.12500000
4           6   12 0.08333333 0.08333333
5           6   20 0.05000000 0.05000000
 
l2 = likelihoods3(dice, c(6, 4, 8, 7, 7, 2))
> l2
   observation roll likelihood      score
1            6    4 0.25000000 0.00000000
2            4    4 0.25000000 0.25000000
3            8    4 0.25000000 0.00000000
4            7    4 0.25000000 0.00000000
5            7    4 0.25000000 0.00000000
6            2    4 0.25000000 0.25000000
7            6    6 0.16666667 0.16666667
8            4    6 0.16666667 0.16666667
9            8    6 0.16666667 0.00000000
10           7    6 0.16666667 0.00000000
11           7    6 0.16666667 0.00000000
12           2    6 0.16666667 0.16666667
13           6    8 0.12500000 0.12500000
14           4    8 0.12500000 0.12500000
15           8    8 0.12500000 0.12500000
16           7    8 0.12500000 0.12500000
17           7    8 0.12500000 0.12500000
18           2    8 0.12500000 0.12500000
19           6   12 0.08333333 0.08333333
20           4   12 0.08333333 0.08333333
21           8   12 0.08333333 0.08333333
22           7   12 0.08333333 0.08333333
23           7   12 0.08333333 0.08333333
24           2   12 0.08333333 0.08333333
25           6   20 0.05000000 0.05000000
26           4   20 0.05000000 0.05000000
27           8   20 0.05000000 0.05000000
28           7   20 0.05000000 0.05000000
29           7   20 0.05000000 0.05000000
30           2   20 0.05000000 0.05000000

Now we need to iterate over the data frame, grouping by ‘roll’ so that we end up with one row for each one.

We’ll add a new column which stores the posterior probability for each dice. This will be calculated by multiplying the prior probability by the product of the ‘score’ entries.

This is what our new likelihood function looks like:

likelihoods3 = function(names, observations) {
  l = list(observation = observations, roll = names)
  obsDf = do.call(expand.grid,l) %>% 
    mutate(likelihood = 1.0 / roll, 
           score = ifelse(roll < observation, 0, likelihood))   
 
  return (obsDf %>% 
    group_by(roll) %>% 
    summarise(s = (1.0/length(names)) * prod(score) ) %>%
    ungroup() %>% 
    mutate(weighted = s / sum(s)) %>%
    select(roll, weighted))
}
 
l1 = likelihoods3(dice, c(6))
> l1
Source: local data frame [5 x 2]
 
  roll  weighted
1    4 0.0000000
2    6 0.3921569
3    8 0.2941176
4   12 0.1960784
5   20 0.1176471
 
l2 = likelihoods3(dice, c(6, 4, 8, 7, 7, 2))
> l2
Source: local data frame [5 x 2]
 
  roll    weighted
1    4 0.000000000
2    6 0.000000000
3    8 0.915845272
4   12 0.080403426
5   20 0.003751302

We’ve now got the same result as we did with our nested for loops so I think the refactoring has been a success.

Categories: Blogs

12 Failure Modes of an Agile Transformation

Rally Agile Blog - Wed, 04/22/2015 - 21:15

The year? 2015. The setting? An Agile transformation near you. The problem? You’ve hit a wall. Despite all your best intentions, you’re still not getting those promised benefits of Agile: speed, quality, value, sustainable growth across your organization. And your problems don’t stop there. You aren’t responding to market threats; you can’t even see market threats; you’re unable to retain great employees; you’re not an industry showcase. In the end, your Agile transformation has brought cynicism and distrust.

You may have heard me talk about “12 Agile Adoption Failure Modes” that concentrated on agile failure in the context of IT teams. Given the expanded adoption of Agile practices in organizations beyond the IT group, the threat of failure is now farther-reaching, with bigger impact.

Now it’s imperative that we look not just at Agile adoption, but at Agile transformation — where organizations move beyond Agile principles within their IT groups to business agility. To accomplish this, we transform from just doing Agile to being Agile.

Over the next few weeks I’ll share with you the top 12 failure modes of an Agile transformation that I’m witnessing in my work with organizations around the globe. The first three center around LEADERSHIP.

1. Lack of Executive Sponsorship

 photo via Flickr CC

This failure mode evidences itself in several different ways and ultimately, it warrants its spot as the number one failure mode and drives all the other failure modes. Also known as “buzzword buy-in,” a lack of executive sponsorship can come at you from two directions

Imagine a small group of techies eager to adopt Agile in their team. With no executive sponsorship, they perform in a stealth environment — sort of a “skunkworks” adoption — under the radar of the existing organizational structure. Why? Because they’re hiding from the hierarchy of management (see the second failure mode, below) which could shut down their effort, and evading the current gate-driven approach to product delivery. While the project may gain some momentum, deliver value faster, and stir the souls of those involved, its sustainability is improbable. Lack of executive sponsorship will limit visibility into the team’s success and provide insufficient support for adoption across subsequent teams. Agile adopted this way will likely die.

In our second scenario, an executive decrees a switch to Agile delivery across the entire IT organization, but there’s no real follow-through: it’s simply a “checkbook commitment.” The executive demands immediate results, yet doesn’t change the metrics by which success is measured. Unengaged, the executive proclamation for an Agile adoption will never move to a true business transformation. At best, without the executive’s continued engagement, the organization will only have pockets of Agile success, typically limited to the team level. The organization will probably grow to blame Agile (and each other) for decreased quality and productivity. And the executive’s resignation letter will conveniently not include the word “Agile” in its summary of successes.

How do we prevent this failure? Leaders must accept that a successful transformation is a journey. Along this journey, leaders seek guidance for a transformation with a broad, sustainable impact. As part of the transformation they make a personal commitment to their teams, and in turn they recognize the personal commitment they are asking of their employees. Executives commit to measuring success differently from before, because the work is different from before. Success now favors value delivery, and time for learning is built into the transformation. Ultimately, success is celebrated across the organization and setbacks are seen not as failures or cause for blame, but as opportunities for learning and growth.

2. Failure to Transform Leader Behaviors

Isn’t it great to have managers who just get things done? They know the right actions to achieve success; they direct their teams to perform these actions; and they have the power to control all aspects of the work and do whatever it takes to get it done.

Huh?

Let’s pull this apart a little. When a manager tells the team what to do, there’s a false sense of success via control. When a manager powers through difficult circumstances regardless of the impact on the team, they leave the wisdom and the morale of the team behind.

 photo via Flickr Commons

Such a management style is a classic Agile transformation failure mode. All the team-level Agile practices in the world mean nothing if the manager doesn’t embrace a behavior that is more in service to the team than control of the team. Robert Greenleaf’s work identifies the characteristics of what he calls a “servant leader”: one who serves by leading, and leads by serving. An Agile transformation success story hinges on the ability of the leaders in the organization to take on these characteristics:

  • Systematic neglect: knows the limits of how much focus can be allocated to issues; learns what to focus on and what to let go of in order to support the team and achieve goals effectively

  • Acceptance: knows when to let go and trust the instincts of the team; accepts the wisdom of the team and is prepared to support it

  • Listening: facilitates useful and necessary communication, pays attention to what remains unspoken, and is motivated to actively hear what others are saying

  • Language: speaks effectively and non-destructively; clearly and consistently articulates the vision and goals for the team

  • Values: is responsible for building a personal sense of values that are clearly exhibited through consistent actions; supports team behaviors that build their sense of values

  • Tolerance of imperfection: modulates his or her own sense of perfection and offers to each team member an understanding of their strengths and challenges; cares more about “How can I help the team grow?”

  • Goal setting: owns the vision; doesn’t advocate for a personal belief in what is right but rather maintains the goal for a higher purpose, inviting others to align with the vision for the overall good

  • Personal growth: recognizes the value of continually finding diverse disciplines that invite new ways of acting in service to the team, and models this growth behavior to inspire others

  • Withdrawal: knows when to step back and allow the team to figure out its course, versus inflicting a personal sense of what is right for the team; carefully decides what to bring forward and when

3. No Change to the Organizational Infrastructure

What is your current organizational structure? How many layers of management exist around each Agile team? How is governance perceived, and who is ready to break down walls to make sure that value flows through your organization?

 photo via Flickr CC

Failed Agile transformations suffer from an inability to change the existing organizational structure. What do I mean by this? Typical organizations have been set up for sub-optimization: that is, they measure success by departmental performance, versus overall value delivery. Here’s what that looks like: In the book This Is Lean, authors Niklas Modig and Par Ahlstrom depict a soccer field scattered with teams, each one in its own tent. Success is defined as any one team getting the ball out of its tent. But is that really success overall? In this scenario, as in our traditional organizations, we create accidental adversaries. We limit visibility of the organization’s overall effectiveness, and focus on our team’s success at the expense of success for the organization.  

True Agile transformations push the boundaries of these existing organizational hierarchies. In the soccer field metaphor, we remove the tents. Now everyone can see where the ball is, where everyone else is, where the goal is positioned, what the referee is indicating, what the coach is saying, and what the scoreboard says. In your effective Agile transformation, you know what the true value is, you know who needs to be involved in order for the value to be delivered, and everyone associated with the value delivery has visibility into the current state of the value stream, including its blocks. They see the goal as successful delivery of value to the customer, and they coordinate as a whole to deliver that value.

Here’s another symptom that your organizational infrastructure is crippling your Agile transformation: Does your organization cling to a notion of efficiency based on resource usage — believing that loading people to 100% capacity is the best way to get work done, and then measuring people annually by how well they deliver in this fully-loaded mode?

To incent greater collaboration and communication, you need to revisit how you appraise work. Instead of annually, by individual, 100% utilized, with MBOs set 12 months earlier, you should invite frequent feedback; focus more on team effectiveness; and bias performance appraisal toward efficiency of value flow versus efficiency of workers.

If you’re not feeling the discomfort change brings, you aren’t truly transforming. If your transformation isn’t requiring you to invest in the technology and culture to support a new mode of visibility and collaboration, you aren’t truly transforming. If you’re adopting some Agile practices at the project level without looking at the bigger picture, your Agile transformation is poised for failure. And Agile, not the failure to transform the organization, will get the blame.


Read about the next three Agile transformation failure modes.

Jean Tabaka
Categories: Companies

12 Failure Modes of an Agile Transformation

Rally Agile Blog - Wed, 04/22/2015 - 21:15

The year? 2015. The setting? An Agile transformation near you. The problem? You’ve hit a wall. Despite all your best intentions, you’re still not getting those promised benefits of Agile: speed, quality, value, sustainable growth across your organization. And your problems don’t stop there. You aren’t responding to market threats; you can’t even see market threats; you’re unable to retain great employees; you’re not an industry showcase. In the end, your Agile transformation has brought cynicism and distrust.

You may have heard me talk about “12 Agile Adoption Failure Modes” that concentrated on agile failure in the context of IT teams. Given the expanded adoption of Agile practices in organizations beyond the IT group, the threat of failure is now farther-reaching, with bigger impact.

Now it’s imperative that we look not just at Agile adoption, but at Agile transformation — where organizations move beyond Agile principles within their IT groups to business agility. To accomplish this, we transform from just doing Agile to being Agile.

Over the next few weeks I’ll share with you the top 12 failure modes of an Agile transformation that I’m witnessing in my work with organizations around the globe. Following are the first three.

1. Lack of Executive Sponsorship

This failure mode evidences itself in several different ways and ultimately, it warrants its spot as the number one failure mode and drives all the other failure modes. Also known as “buzzword buy-in,” a lack of executive sponsorship can come at you from two directions

Imagine a small group of techies eager to adopt Agile in their team. With no executive sponsorship, they perform in a stealth environment — sort of a “skunkworks” adoption — under the radar of the existing organizational structure. Why? Because they’re hiding from the hierarchy of management (see the second failure mode, below) which could shut down their effort, and evading the current gate-driven approach to product delivery. While the project may gain some momentum, deliver value faster, and stir the souls of those involved, its sustainability is improbable. Lack of executive sponsorship will limit visibility into the team’s success and provide insufficient support for adoption across subsequent teams. Agile adopted this way will likely die.

In our second scenario, an executive decrees a switch to Agile delivery across the entire IT organization, but there’s no real follow-through: it’s simply a “checkbook commitment.” The executive demands immediate results, yet doesn’t change the metrics by which success is measured. Unengaged, the executive proclamation for an Agile adoption will never move to a true business transformation. At best, without the executive’s continued engagement, the organization will only have pockets of Agile success, typically limited to the team level. The organization will probably grow to blame Agile (and each other) for decreased quality and productivity. And the executive’s resignation letter will conveniently not include the word “Agile” in its summary of successes.

How do we prevent this failure? Leaders must accept that a successful transformation is a journey. Along this journey, leaders seek guidance for a transformation with a broad, sustainable impact. As part of the transformation they make a personal commitment to their teams, and in turn they recognize the personal commitment they are asking of their employees. Executives commit to measuring success differently from before, because the work is different from before. Success now favors value delivery, and time for learning is built into the transformation. Ultimately, success is celebrated across the organization and setbacks are seen not as failures or cause for blame, but as opportunities for learning and growth.

2. Failure to Transform Leader Behaviors

Isn’t it great to have managers who just get things done? They know the right actions to achieve success; they direct their teams to perform these actions; and they have the power to control all aspects of the work and do whatever it takes to get it done.

Huh?

Let’s pull this apart a little. When a manager tells the team what to do, there’s a false sense of success via control. When a manager powers through difficult circumstances regardless of the impact on the team, they leave the wisdom and the morale of the team behind.

Such a management style is a classic Agile transformation failure mode. All the team-level Agile practices in the world mean nothing if the manager doesn’t embrace a behavior that is more in service to the team than control of the team. Robert Greenleaf’s work identifies the characteristics of what he calls a “servant leader”: one who serves by leading, and leads by serving. An Agile transformation success story hinges on the ability of the leaders in the organization to take on these characteristics:

  • Systematic neglect: knows the limits of how much focus can be allocated to issues; learns what to focus on and what to let go of in order to support the team and achieve goals effectively

  • Acceptance: knows when to let go and trust the instincts of the team; accepts the wisdom of the team and is prepared to support it

  • Listening: facilitates useful and necessary communication, pays attention to what remains unspoken, and is motivated to actively hear what others are saying

  • Language: speaks effectively and non-destructively; clearly and consistently articulates the vision and goals for the team

  • Values: is responsible for building a personal sense of values that are clearly exhibited through consistent actions; supports team behaviors that build their sense of values

  • Tolerance of imperfection: modulates his or her own sense of perfection and offers to each team member an understanding of their strengths and challenges; cares more about “How can I help the team grow?”

  • Goal setting: owns the vision; doesn’t advocate for a personal belief in what is right but rather maintains the goal for a higher purpose, inviting others to align with the vision for the overall good

  • Personal growth: recognizes the value of continually finding diverse disciplines that invite new ways of acting in service to the team, and models this growth behavior to inspire others

  • Withdrawal: knows when to step back and allow the team to figure out its course, versus inflicting a personal sense of what is right for the team; carefully decides what to bring forward and when

3. No Change to the Organizational Infrastructure

What is your current organizational structure? How many layers of management exist around each Agile team? How is governance perceived, and who is ready to break down walls to make sure that value flows through your organization?

Failed Agile transformations suffer from an inability to change the existing organizational structure. What do I mean by this? Typical organizations have been set up for sub-optimization: that is, they measure success by departmental performance, versus overall value delivery. Here’s what that looks like: In the book This Is Lean, authors Niklas Modig and Par Ahlstrom depict a soccer field scattered with teams, each one in its own tent. Success is defined as any one team getting the ball out of its tent. But is that really success overall? In this scenario, as in our traditional organizations, we create accidental adversaries. We limit visibility of the organization’s overall effectiveness, and focus on our team’s success at the expense of success for the organization.  

True Agile transformations push the boundaries of these existing organizational hierarchies. In the soccer field metaphor, we remove the tents. Now everyone can see where the ball is, where everyone else is, where the goal is positioned, what the referee is indicating, what the coach is saying, and what the scoreboard says. In your effective Agile transformation, you know what the true value is, you know who needs to be involved in order for the value to be delivered, and everyone associated with the value delivery has visibility into the current state of the value stream, including its blocks. They see the goal as successful delivery of value to the customer, and they coordinate as a whole to deliver that value.

Here’s another symptom that your organizational infrastructure is crippling your Agile transformation: Does your organization cling to a notion of efficiency based on resource usage — believing that loading people to 100% capacity is the best way to get work done, and then measuring people annually by how well they deliver in this fully-loaded mode?

To incent greater collaboration and communication, you need to revisit how you appraise work. Instead of annually, by individual, 100% utilized, with MBOs set 12 months earlier, you should invite frequent feedback; focus more on team effectiveness; and bias performance appraisal toward efficiency of value flow versus efficiency of workers.

If you’re not feeling the discomfort change brings, you aren’t truly transforming. If your transformation isn’t requiring you to invest in the technology and culture to support a new mode of visibility and collaboration, you aren’t truly transforming. If you’re adopting some Agile practices at the project level without looking at the bigger picture, your Agile transformation is poised for failure. And Agile, not the failure to transform the organization, will get the blame.


Stay tuned to the blog for Jean’s next three Agile transformation failure modes.

Jean Tabaka
Categories: Companies

The Story of a Digital Artist

J.D. Meier's Blog - Wed, 04/22/2015 - 17:35

I’m always on the hunt for people that do what makes them come alive.

Artists in particular are especially interesting for me, especially when they are able to do what they love.

I’ve known too many artists that lived painful lives, trying to be an artist, but never making ends meet.

I’ve also known too many artists that lived another life outside of art, but never really lived, because they never answered their calling.

I believe that in today’s world, there are a lot more options for you to live life on you terms.

With technology at our fingertips, it’s easier to connect with people around the world and share your art, whatever that may be.

On Sources of Insight, I’ve asked artist Rebecca Tsien to share her story:

Why I Draw People and Animals

It’s more than a story of a digital artist.   It’s a journey of fulfillment.

Rebecca has found a way to do what she loves.  She lives and breathes her passion.

Maybe her story can inspire you.

Maybe there’s a way you can do more art.

Categories: Blogs

How to Build a Community of Evangelists for Your Software Product

Pivotal Tracker Blog - Wed, 04/22/2015 - 17:06

We all want customers to crave the products we build. Next, we want them to spread the word, because word-of-mouth (WOM) marketing is the strongest and most authentic for your product.

WOM is a testimonial delivered from one customer to another. The customer spreading the word cares about helping the other person out and is willing to vouch for the product based on benefits they’ve personally experienced.

These days, most customer-to-customer testimonials live on the internet through social media, forums, forwarded emails, and other online communities.

They also live on Product Hunt, TechCrunch’s Best New Startup of 2014.

Product Hunt is an online community where members submit and vote up the best new tech products. A simple upvote arrow is the site’s distilled version of word of mouth, and highly recommended products float to the top of the site and get an influx of visitors. According to TechCrunch, Product Hunt is “taking the industry by storm as founders, investors, early adopters and other tech enthusiasts now check the site on a daily basis.”

Recommendation-driven user acquisitions aren’t the only benefit for products that succeed on Product Hunt; they might also nab press coverage, investor interest, or high-quality feedback from the tech enthusiasts.

When Product Hunt was just getting started, it faced a classic chicken-and-egg problem that typically burdens community-based products. You need users on your home turf to attract other users, but how do you go from zero initial users to 10 or 100?

Product Hunt did a phenomenal job building up a following. The founder, Ryan Hoover, started with a simple email list that grew into a strong community of evangelists eager to use the product every day.

In today’s episode of Femgineer TV, we’ll cover how he did it. Any new startup—even if it’s not social or community based—can use these strategies to drive word-of-mouth recommendations for their product.

I’ve invited Ryan Hoover and his founding team member Erik Torenberg to candidly share how they used evangelists to accelerate Product Hunt’s growth in the early days. They’ll also explain how they continue to build fervor for the product through an engaged and growing community.

Watch the episode to learn:

  • what they did to create a positive first impression of their company on prospective users and influencers
  • how they attracted early adopters even before Product Hunt was built
  • how they mobilized their early adopters to evangelize the product and bring in more users
  • strategies that did and didn’t work to increase community engagement
  • how they keep users hooked and coming back

If you’re struggling to get traction for your software product, watch the episode. You’ll definitely walk away with some valuable insights to apply to your business right away!

Viewer’s Challenge

After you’ve watched the episode, take our challenge. Let us know the following in the comments below:

  • How do you think about your customers’ first-time experience and how do you know whether it’s contributing to customer acquisition and retention?
  • How do you pull your customers back into your product and keep them engaged?
  • If your product has a community, what were some of the key steps you took to build it, and how has it changed over time?

The three best responses will receive a special giveaway from our sponsor Pivotal Tracker and will be showcased in Femgineer’s weekly newsletter!

Submit your responses in the blog comments below by April 22nd at 11:59pm PST.

The next episode of Femgineer TV airs in May. I’ll be hosting Indi Young, the founder of Adapative Path, a user experience consultant, and author of two books: Mental Models and, most recently, Practical Empathy. Subscribe to our YouTube channel to know when it’s out!

The post How to Build a Community of Evangelists for Your Software Product appeared first on Pivotal Tracker.

Categories: Companies

Coming Soon: RabbitMQ For Developers

Derick Bailey - new ThoughtStream - Wed, 04/22/2015 - 16:32

A few months ago, I started working on a screencast series for WatchMeCode that covers RabbitMQ – a great little messaging system that allows you to quickly and easily write distributed applications by using message queues. The screencast series is done, and it’s been a rather popular one already. But I also realize that there’s a lot of additional information out there, that would be very useful for other developers to have.

When it comes to figuring out how to organize your RabbitMQ topology – that is, the exchanges, queues and bindings – there isn’t a lot of information around. You can get a few bits of info from a dozen sources and put it all together with trial and error to see how things work best, but there hasn’t been a single place to go to for this info.

There is also a lot of expert knowledge on what messaging can do for you, in the minds of other developers that are working in this space. People that are working in RabbitMQ and other messaging systems are using messages to do some amazing things.

I want to bring more of this knowledge to the rest of us – the “it depends…” that developers, architects and experts in the world of message based architectures collect over years of experience. So I am.

The Bundle With All Of This

With all that in mind, I am working on building a package that will be available to everyone, to help you get up and running with RabbitMQ quickly!

You will learn the how-to’s of working with RabbitMQ and using NodeJS to send / receive messages. You’ll learn the why-to’s of each exchange type with RabbitMQ, and why you may or may not want to use a specific option in a specific scenario. You’ll see interviews with industry experts, authors and developers that work with RabbitMQ on a daily basis. And you’ll receive some extra bonus materials – things that I’m not yet ready to announce!

With all of these resources coming together, this will certainly be a high value package for any developer that is working with RabbitMQ or is curious about where and why they would want to work with RabbitMQ.

The Screencasts

I have the screencasts, which I’ve already released to my WatchMeCode subscribers. These screencasts are aimed at NodeJS developers that want to get up and running with distributed systems very quickly. I’ll walk you through the installation, basic configuration and use of RabbitMQ with NodeJS and ExpressJS applications. It’s a 12 episode, multi-hour long series of screencasts that builds on each other as it goes.

NewImage NewImage NewImage

The screencasts (only 3 of the 12 shown here) are done and in the bag, already. Any subscriber to WatchMeCode will already have access to these – but not to the rest of the material! The eBook, the interviews and the bonuses that I have planned are going to be saved for the full package when it releases.

The eBook

Over the last month or so, I’ve been working on my own eBook that is tackling the problem of figuring out your options with RabbitMQ, trying to understand which of the many exchange types is the best one for a given scenario, etc. I’ve got the eBook about 90% done at this point, and should be finishing it soon.

NewImage

This isn’t just another technical book with lots of boring detail about API’s, though. Sure, I do cover a few technical bits when it comes to understanding the different types of exchanges. But the majority of this book – and the real value that it offers – is a very different approach to teaching technical content.

From the books’ preface, and “about this book”:

Rather than providing a strictly technical approach to show you how to use RabbitMQ, part 2 takes a story-telling approach to guide you through the decision making paths of real world projects and systems. Through a narrative style that puts you in the mind of another developer, you will see the struggles, the success and some of the failures in designing a message based system with RabbitMQ.

Chapter 5 will show a sample job scheduling application, following a developer through a decision to implement RabbitMQ and organize it appropriately. The running jobs in the schedule can be put in to various states through an administrative web application, but how should the queues and exchanges be organized to facilitate this? The inspiration for the solution seems to come out of nowhere.

Chapter 6 follows a developer through the often painful process of discovering and documenting performance problems, and finding solutions to the issue. RabbitMQ is already in place, in this case, but was it the right thing to do? Should RabbitMQ be taken out of the equation in order to reduce the latency between requesting a download and actually sending the file back to the user? Find out whether or not RabbitMQ makes the cut in this story of struggling to improve the performance of a file sharing service.

And there’s far more to the book than just these 2 chapters. I’ve got several more written already, and at least one more to come – all with the goal of putting you inside the mind of another developer as they learn, struggle, succeed and sometimes fail their way in to a solid RabbitMQ structure.

The Interviews

In the last few weeks, I have also been scheduling and recording interviews with experts in the world of messaging based architectures. The list of people that I am interviewing is quite impressive already, and it’s still growing. I have persons from some very large and notable companies, authors of some of my favorite books, frameworks and plugins, developers and architects that are leading their team down a very successful path with messaging, and more!

NewImageNewImage

These interviews are each focused on a specific area of expertise for every guest. From architectural concepts like CQRS, to long running “transactions” in Sagas, error handling and failures to production requirements for RabbitMQ, these interviews will provide a new level of insight in to what RabbitMQ can and should do for you, your current applications and beyond.

Shut Up And Take My Money!

Sorry, but I can’t just yet…

There’s a lot of work left to make sure this is the best possible package to help you get up and running quickly. I’m working on it as fast as I can! But, it will be a few more weeks before the raw material is complete, and possibly a few weeks after that to ensure everything is packaged properly. But it’s coming… and it will be here soon!

If you’re interested in staying up to date with what I’m doing in this package, be sure to join my mailing list. You’ll receive updates on the progress of the bundle, and you’ll get a hefty discount when this thing ships! You won’t want to miss the discount, either… this will be the largest discount that will ever be available for this package deal!

 

Join My List and Get Updates On This Bundle!

 

 

Categories: Blogs

Scaling Agile? Keep it simple, scaler!

Xebia Blog - Wed, 04/22/2015 - 09:59

The promise of Agile is short cycled value delivery, with the ability to adapt. This is achieved by focusing on the people that create value and optimising the way they work.

Scrum provides a framework that provides a limited set of roles and artefacts and offers a simple process framework that helps to implement the Agile values and to adhere to the Agile principles.

I have supported many organisations in adopting Agile as their mindset and culture. What puzzles me is that many larger organisations seem to think that Scrum is not enough in their context and they feel the need for something bigger and more complicated. As a result of this, more and more Agile transformations start with scaling Agile to fit their context and then try to make things less complex.

While the various scaling frameworks for Agile contain many useful and powerful tools to apply in situations that require them, applying a complete Agile scaling framework to an organisation from the get-go often prevents the really needed culture and mindset change.

When applying a little bit of creativity, already present organisational structure can be mapped easily on the structure suggested by many scaling frameworks. Most frameworks explain the needed behaviour in an Agile environment, but these explanations are often ignored or misinterpreted. Due to (lengthy) descriptions of roles and responsibilities, people tend to stop thinking for themselves about what would work best and start to focus on who plays which role and what is someone else’s responsibility. There is a tendency to focus on the ceremonies rather than on the value that should be delivered by the team(s) with regards to product or service.

My take on adopting Agile would be to start simple. Use an Agile framework that prescribes very little, like Scrum or Kanban, in order to provoke learning and experiencing. From this learning and experiencing will come changes in the organisational structure to best support the Agile Values and Principles. People will find or create positions where their added value has most impact on the value that the organisation creates and, when needed, will dismantle positions and structure that prevent this value to be created.

Another effect of starting simple is that people will not feel limited by rules and regulations, and that way use their creativity, experience and capabilities easier. Oftentimes, more energy is create by less rules.

As said by others as well, some products or value are difficult to create with simple systems. As observed by Dave Snowden and captured in his Cynefin framework, too much simplicity could result in chaos when this simplicity is applied to complex systems. To create value in more complex systems, use the least amount of tools provided by the scaling frameworks to prevent chaos and leverage the benefits that simpler systems provide. Solutions to fix problems in complex systems are best found when experiencing the complexity and discovering what works best to cope with that. Trying to prevent problems to pop up might paralyse an organisation too much to put out the most possible value.

So: Focus on delivering value in short cycles, adapt when needed and add the least amount of tools and/or process to optimise communication and value delivery.

Categories: Companies

A Dreyfus model for Agile adoption

lizkeogh.com - Elizabeth Keogh - Wed, 04/22/2015 - 09:30

A couple of people have asked for this recently, so just posting it here to get it under the CC licence. It was written a while ago, and there are better maturity models out there, but I still find this useful for showing teams a roadmap they can understand.

If you want to know more about how to create and use your own Dreyfus models, this post might help.

What does an Agile Team look like? Novice

We have a board
We put our stories on the board
Every two weeks, we get together and celebrate what we’ve done
Sometimes we talk to the stakeholders about it
We think we might miss our deadline and have told our PM
Agile is really hard to do well

Beginner

We are trying to deliver working software
We hold retrospectives to talk about what made us unhappy
When something doesn’t work, we ask our coach what to do about it
Our coach gives us good ideas
We have delegated someone to deal with our offshore communications
We have a great BA who talks to the stakeholders a lot
We know we’re going to miss our deadline; our PM is on it
Agile requires a great deal of discipline

Practitioner

We know that our software will work in production
Every two weeks, we show our working software to the stakeholders
We talk to the stakeholders about the next set of stories they wants us to do
We have established a realistic deadline and are happy that we’ll make it
We have some good ideas of our own
We deal with blockers promptly
We write unit tests
We write acceptance tests
We hold retrospectives to work out what stopped us delivering software
We always know what ‘done’ looks like before we start work
We love our offshore team members; we know who they are and what they look like and talk to them every day
Our stakeholders are really interested in the work we’re doing
We always have tests before we start work, even if they’re manual
We’ve captured knowledge about how to deploy our code to production
Agile is a lot of fun

Knowledgeable

We are going to come well within our deadline
Sometimes we invite our CEO to our show-and-tell, so he can see what Agile looks like done well
People applaud at the end of the show-and-tell; everyone is very happy
That screen shows the offshore team working; we can talk to them any time; they can see us too
We hold retrospectives to celebrate what we learnt
We challenge our coach and change our practices to help us deliver better
We run the tests before we start work – even the manual tests, to see what’s broken and know what will be different when we’re done
Agile is applicable to more than just software delivery

Expert

We go to conferences and talk about our fantastic Agile experiences
We are helping other teams go Agile
Business outside of IT are really interested in what we’re doing
We regularly revisit our practices, and look at other teams to see what they’re doing
The company is innovative and fun
The company are happy to try things out and get quick feedback
We never have to work late or weekends
We deploy to production every two weeks*
Agile is really easy when you do it well!

* Wow, this model is old.


Categories: Blogs

Single Tasking und positive Verstärkung – ein Selbstexperiment

Scrum 4 You - Wed, 04/22/2015 - 08:05

Nach dem Training “Selbstorganisation braucht Führung” und unserem internen Consulting Day zum Schwerpunkt Zeitmanagement beschließe ich, an meiner eigenen Selbstorganisation zu arbeiten und die gewonnenen Erkenntnisse in die Tat umzusetzen. Also beginne ich mit einem Selbstexperiment zum Thema Single Tasking und positive Verstärkung. Für alle, die sich darunter nichts vorstellen können: Single Tasking bedeutet, sich auf einen Task nach dem anderen zu konzentrieren, während man beim Multitasking zwischen zwei oder mehreren Aufgaben hin und her wechselt. Ein kleines Experiment zu den schädlichen Auswirkungen auf die Produktivität findet sich hier. Zum Thema positive Verstärkung sei nur gesagt: Es wirkt wesentlich motivierender auf einen Menschen, wenn er positiv statt negativ bestärkt wird. Das Paradebeispiel dafür ist das Casino: Spieler verlieren sehr oft (negative Verstärkung), aber gewinnen sehr selten (positive Verstärkung) – trotzdem gibt es viele Spielsüchtige. Grund dafür ist besagte positive Verstärkung, die eben weitaus stärker wirkt.

Start – Tag 1

19:40
Die Idee zum Selbstexperiment ist geboren. Ich beschließe, für jeden Single Tasking Vorgang 1 Euro von meinem eigenen Budget zu kassieren, den ich anschließend für meine Belohnung ausgeben darf (positive Verstärkung). Derzeit denke ich noch, dass ich mit dieser Methode ziemlich schnell bankrott bin.

19:50
Erster Euro eingeheimst für den Download der Counter App für dieses Experiment. Ha! Parallel stelle ich jedoch fest, dass sich dieser Vorgang fast wie ein Purzelbaum im Hirn anfühlt. Ich scheine selten Gedankengänge oder Tätigkeiten zu Ende zu bringen, ohne mittendrin etwas Neues anzufangen. Und ich dachte, ich wäre Single Task Profi …

20:10
Ein weiterer Euro hinzugefügt und gleich wieder abgezogen, da ich mitten in der Tätigkeit meine Counter App gezückt habe, um den Punkt zu registrieren. Ich frage mich, ob mein Hirn aus irgendeinem Grund süchtig nach Multitasking ist – beschließe, der Sache auf dem Grund zu gehen und einen Blogbeitrag darüber zu schreiben. Parallel stelle ich aber fest, dass der alleinige Versuch, bei einer Sache bleiben zu wollen, einen Entspannungseffekt produziert. Die Aufgabe befreit mich davon, unentwegt und gleichzeitig an unterschiedliche Themen denken zu wollen.

20:22
Während ich diesen Blog schreibe, stelle ich fest, dass mich mein Mac gerade meinen Belohnungseuro gekostet hat. Ein Pop-up mit dem Wunsch nach einer Passworteingabe für die Cloud, darauf folgende Falscheingaben und der Ärger darüber haben es mir nicht ermöglicht, kontinuierlich hier weiterzuschreiben. Verhindert sogar mein Computer das erfolgreiche Single Tasking?

20:38
Bewerbung eines Bewerbers in einem Zug gelesen und somit für Bewerbungsgespräch vorbereitet. Punkt gesammelt. Interessanter Nebeneffekt: Positive Verstärkung wirkt auch, wenn ich es bei mir selbst durchführe und weiß, warum ich es tue.

21:17
Computer sind eindeutig hinderlich beim Single Tasking. Selbst mit einem Apple scheint es unmöglich, eine Aufgabe durchzuführen, ohne mittendrin durch ein Pop-up unterbrochen zu werden. Falls das mal nicht der Fall ist, ist die Internetverbindung so langsam, dass es kaum möglich ist, bei der Sache zu bleiben.

Tag 2

09:59
Ich stelle fest, wie schwierig es ist, dranzubleiben und eine Sache unterbrechungsfrei zu machen. Einerseits sind die Leute in meiner Umgebung ebenfalls gewohnt, durch unterschiedliche Themen zu springen, andererseits stellen reinkommende Nachrichten sowie Informationen von Handy und Laptop das zweite große Hindernis dar.

17:03
Nachdem ich streckenweise gar keinen Punkt bekommen habe, kann ich mir abends gleich mehrere Punkte holen. Auf Anraten von Boris habe ich ein Bullet Journal erstellt und mit Extreme Timeboxing begonnen. Ergebnis: Ich bin von 3 auf 11 Punkte gesprungen, die jetzt auch gleich in Dinge investiert werden, die mir Spaß machen. :)

Resumee

  1. Single Tasking befreit ungemein und ermöglicht es, zufrieden nach Hause zu gehen.
  2. Ohne externe Maßnahmen wie eine gut geführte Aufgabenliste und konsequentes Timeboxing ist es wegen der vielen Ablenkungen fast unmöglich, bei nur einer Sache zu bleiben.
  3. Positive Verstärkung zieht. Sogar wenn man sein eigenes Budget dafür ausgeben darf – klingt seltsam, ist aber erfreulicherweise so.

Eigentlich ist die Sache damit erledigt. Aber wir kennen doch den guten alten Schweinehund, der wieder auflauert, wenn man gerade wegschaut. Ich beschließe, die Langzeiteffekte zu prüfen.

To be continued

Categories: Blogs

Protecting Agile Projects from Consultants

TV Agile - Wed, 04/22/2015 - 07:58
Zigurd Mednieks explains why you should protect Agile projects from the consultants. Consultants can drive a software project to enormous success, but sometimes they drive the project off the rails instead. Managers must know when to check up on an agile project and what questions to ask to make sure the consultant doesn’t run away […]
Categories: Blogs

Measurements Towards Continuous Delivery

Learn more about our Scrum and Agile training sessions on WorldMindware.com

I was asked yesterday what measurements a team could start to take to track their progress towards continuous delivery. Here are some initial thoughts.

Lead time per work item to production

Lead time starts the moment we have enough information that we could start the work (ie it’s “ready”). Most teams that measure lead time will stop the clock when that item reaches the teams definition of “done” which may or may not mean that the work is in production. In this case, we want to explicitly keep tracking the time until it really is in production.
Note that when we’re talking about continuous delivery, we make the distinction between deploy and release. Deploy is when we’ve pushed it to the production environment and release is when we turn it on. This measurement stops at the end of deploy.

Cycle time to “done”

If the lead time above is excessively long then we might want to track just cycle time. Cycle time starts when we begin working on the item and stops when we reach “done”.
When teams are first starting their journey to continuous delivery, lead times to production are often measured in months and it can be hard to get sufficient feedback with cycles that long. Measuring cycle time to “done” can be a good intermediate measurement while we work on reducing lead time to production.

Escaped defects

If a bug is discovered after the team said the work was done then we want to track that. Prior to hitting “done”, it’s not really a bug – it’s just unfinished work.
Shipping buggy code is bad and this should be obvious. Continuously delivering buggy code is worse. Let’s get the code in good shape before we start pushing deploys out regularly.

Defect fix times

How old is the oldest reported bug? I’ve seen teams that had bug lists that went on for pages and where the oldest were measured in years. Really successful teams fix bugs as fast as they appear.

Total regression test time

Track the total time it takes to do a full regression test. This includes both manual and automated tests. Teams that have primarily manual tests will measure this in weeks or months. Teams that have primarily automated tests will measure this in minutes or hours.
This is important because we would like to do a full regression test prior to any production deploy. Not doing that regression test introduces risk to the deployment. We can’t turn on continuous delivery if the risk is too high.

Time the build can be broken

How long can your continuous integration build be broken before it’s fixed? We all make mistakes. Sometimes something gets checked in that breaks the build. The question is how important is it to the team to get that build fixed? Does the team drop everything else to get it fixed or do they let it stay broken for days at a time?

Continuous delivery isn’t possible with a broken build.

Number of branches in version control

By the time you’ll be ready to turn on continuous delivery, you’ll only have one branch. Measuring how many you have now and tracking that over time will give you some indication of where you stand.

If your code isn’t in version control at all then stop taking measurements and just fix that one right now. I’m aware of teams in 2015 that still aren’t using version control and you’ll never get to continuous delivery that way.

Production outages during deployment

If your production deployments require taking the system offline then measure how much time it’s offline. If you achieve zero-downtime deploys then stop measuring this one.  Some applications such as batch processes may never require zero-downtime deploys. Interactive applications like webapps absolutely do.

I don’t suggest starting with everything at once. Pick one or two measurements and start there.

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

11 Tips for a Successful Scrum Implementation

Mike Vizdos - Implementing Scrum - Tue, 04/21/2015 - 21:27
www.implementingscrum.com -- Cartoon -- April 21, 2008 Congratulations.

You may have just returned from an internal meeting where you were given some new orders to “go agile” with your team or group.

You may be responsible for leading an agency (or a professional services team) within your organization to “go agile.”

Your team is responsible to #deliver “using agile” or “using scrum” (This last posting may also help — “Holy CRAP I have to do THIS???”)

Now.  The pressure is on for you to do this TODAY.

Actually, YESTERDAY.

Your boss — or some other stakeholder — is demanding results.  Lucky you!

Do you feel a bit out of control or caught between a rock and a hard place?

Are you STUCK?

Here’s the secret:

You CAN enable the team to run in an agile manner using Scrum (or something like it).

How?

It’s pretty easy actually.  In real life, “easy” is anything BUT that (you know there is no Silver Bullet).

Let me help you. Let’s talk.

Or.

Here are TEN FREE STEPS to start on your own:

STEP ZERO:

I have this sinking feeling you may want to do this with all your teams and clients across the organization.  You want to jump in and scale this agile stuff in a big way and just GO FOR IT.

Don’t.

This is not time for you to panic.  This is not the time for you to make a career-limiting-move.

Here is what you can do.

STEP ONE:

Identify your most important (valuable?) client today.

Think about the pareto principle (80/20 rule).

You DO have those very valuable 20% of customers who DO provide you with 80% of your success.

Focus on them and use Scrum to #deliver with them.

Actually. Start with just ONE client (or customer).

Yes.  This means you will have to say NO to a lot of people.

It’s OK.

Remember that 80% of your current clients are keeping you up at night on wasteful non-value-added crap.  You may piss them off by saying NO; however, they are probably already pissed off at you and the cost of switching is either too high or they do not really feel enough pain and love blaming someone anyway.

They are not your problem. If you are bleeding now, this is not the time to keep doing whatever it was that you were doing in the past.

STEP TWO:

Have a real face-to-face conversation with your customer (or client) about playing the role of “Product Owner” for the ONE Scrum Team.

This is a HUGE commitment.  Amazing things happen when you ask.  I’ve seen it done and have helped others do this.  What seems unreasonable today really can happen when you Focus and #deliver together.

STEP THREE:

Now.

Dedicate a team of 5-9 people that can #deliver with your Product Owner on this Scrum Team.

Identify someone to play to role of the ScrumMaster; this person should have real world experience and failures someone else has paid them to make!

And.

Watch the magic happen.

STEP FOUR:

Create an initial Product Backlog together as a Scrum Team.  This should be based on the highest value project with a clear vision of the WHY effectively communicated by the Product Owner.

Don’t worry about estimating at this point.  Read up on the topic of #noEstimates and learn to Focus and #deliver together… as a real team.

STEP FIVE:

The Product Owner can prioritize the Product Backlog items however they feel is necessary.  Use Story Boarding or other ways to tease out the REAL value to your end users.  Oh… and do this quickly (think hours or two days MAX because there is no such thing as a “Sprint Zero”).

STEP SIX:

The Scrum Team can then plan their first Sprint using the Scrum Master as the facilitator.  The Development Team can figure out what to commit to (or forecast) for this Sprint (or Iteration).

Here’s the thing… they will be wrong.  It’s OK.  Focus and #deliver SOMETHING. The weather forecast is rarely right in the real world… but we learn to adjust real life to the real weather conditions as we learn more together.

STEP SEVEN:

Have a daily stand-up meeting each day for a short iteration (how about one week to get started!?!?!).

Allow for the team to coordinate on the Sprint Goal and meeting the Definition of Done for the Sprint.

STEP EIGHT:

Do the work. Daily.  This is where the miracles can happen and will evolve over time as your dedicated team becomes high performing [did I mention this will take time]?

STEP NINE:

At the end of the Sprint, host a Sprint Review.  Demo your Potentially Shippable Software — or Product Increment — together as a Scrum Team.  Have your Product Owner stand up and proudly show what the team was able to actually #deliver.

Gather feedback from your key stakeholders, project sponsors, and perhaps even you real world customers (or end users!).

Focus. #deliver

STEP TEN:

Gather your team for a Sprint Retrospective.

Learn together about what can improved in the next Sprint.

STEP ELEVEN:

Keep going.

That’s it.

Focus. #deliver

Need help?

LET’S TALK

 

 

WARNING The proverbial shit will probably hit the fan. Bad things WILL happen. This is totally normal.

As time takes time, the team DOES #deliver something.

Remember: Delivering the wrong thing TODAY is better than delivering the wrong thing months — or years — from now.

Focus.  #deliver

And.

Keep learning.

This is all good.

Easy.

Right?

I can help.

LET’S TALK

Categories: Blogs

The Myths of Business Model Innovation

J.D. Meier's Blog - Tue, 04/21/2015 - 19:37

Business model innovation has a couple of myths.

One myth is that business model innovation takes big thinking.  Another myth about business model innovation is that technology is the answer.

In the book, The Business Model Navigator, Oliver Gassman, Karolin Frankenberger, and Michaela Csik share a couple of myths that need busting so that more people can actually achieve business model innovation.

The "Think Big" Myth

Business model innovation does not need to be “big bang.”  It can be incremental.  Incremental changes can create more options and more opportunities for serendipity.

Via The Business Model Navigator:

“'Business model innovations are always radical and new to the world.'   Most people associate new business models with the giants leaps taken by Internet companies.  The fact is that business model innovation, in the same way as product innovation, can be incremental.  For instance, Netflix's business model innovation of mailing DVDs to customers was undoubtedly incremental and yet brought great success to the company.  The Internet opened up new avenues for Netflix that allowed the company to steadily evolve into an online streaming service provider.”

The Technology Myth

It’s not technology for technology’s sake.  It’s applying technology to revolutionize a business that creates the business model innovation.

Via The Business Model Navigator:

“'Every business model innovation is based on a fascinating new technology that inspires new products.'  The fact is that while new technologies can indeed drive new business models, they are often generic in nature.  Where creativity comes in is in applying them to revolutionize a business.  It is the business application and the specific use of the technology which makes the difference.  Technology for technology's sake is the number one flop factor in innovation projects.  The truly revolutionary act is that of uncovering the economic potential of a new technology.”

If you want to get started with business model innovation, don’t just go for the home run.

You Might Also Like

Cloud Changes the Game from Deployment to Adoption

Cognizant on the Next Generation Enterprise

Drive Digital Transformation by Re-Imagining Operations

Drive Digital Transformation by Re-envisioning Your Customer Experience

The Future of Jobs

Categories: Blogs

Scrum Alliance Launches Learning Consortium

Scrum Expert - Tue, 04/21/2015 - 18:38
The Scrum Alliance has announced the formation of a Learning Consortium for the Creative Economy. The Learning Consortium comprises a diverse group of organizations in different sectors around the world that are exploring management innovation in the emerging Creative Economy. Learning Consortium organizations include agile42, Autodesk, Brillio, C.H. Robinson International, Ericsson, hhpberlin, Magna International, Menlo Innovations, Microsoft, PENSCO Trust, SolutionsIQ, and SWIFT. The Learning Consortium will explore the leadership and management practices emerging to deal with a marketplace that requires continuous customer-driven innovation. The Consortium will study ongoing transformational shifts ...
Categories: Communities

Crossing the Agile-UX Divide

Scrum Expert - Tue, 04/21/2015 - 17:28
Integrating UX into an Agile process is not always an easy challenge. In this article, Mike Bulajewski reminds the why the differences between the two vision exist in the first place and proposes some solutions on how they could be solved. This article provides a very interesting point of view of the Agile-UX relationship from the UX side. The article starts by reminding the origin of the Agile movement and how it changes the vision from the traditional software development. He thinks that for many agilists, “he mere existence of designers ...
Categories: Communities

No Matter What Your Strategy, You’d Better Deliver Fast!

Rally Agile Blog - Tue, 04/21/2015 - 17:00

Last month, Forrester released a wave of portfolio management industry reports. In the Portfolio Management for Tech Management wave, Rally was named among the ten most significant portfolio management software providers, and was the only Agile vendor featured in the report. The inclusion of a pure Agile vendor reflects the growing importance of executing portfolio plans faster to hit critical market windows.

In midsize to large organizations, delivering business value faster requires scaling Agile practices to coordinate a large number of teams to deliver on an entire portfolio scope. But a good strategy is irrelevant if you can’t deliver on it in the timeframe required to stay competitive. As companies realize this, faster portfolio execution becomes an imperative.

At the same time, many of these companies still have traditional financial controls that impede their ability to respond to market changes: project funding that locks in requirements for long periods of time and mandates that developers leave their environments to fill out timesheets — a process that often results in inaccurate cost reporting.

Changing those financial practices takes time — and you can’t afford to wait. If you work in one of those organizations, you can still scale your Agile practices to deliver faster by integrating the Rally platform with PPM vendors.

Planview — one of the leading PPM vendors — has been honing its integration with the Rally platform for several years to create a realtime connection between traditional portfolio planning and Agile portfolio execution. The latest Rally-Planview integration provides added granularity into the visibility of Agile projects from PPM dashboards. When adopting Agile, the more visibility you can give to business leaders, the faster they can adapt their plans to respond to changes.

The Forrester report recognized Rally for its software integrations with several PPM vendors. To learn how you can accelerate your portfolio execution, take our portfolio management tour.

Catherine Connor
Categories: Companies

No Matter What Your Strategy, You’d Better Deliver Fast!

Rally Agile Blog - Tue, 04/21/2015 - 17:00

Last month, Forrester released a wave of portfolio management industry reports. In the Portfolio Management for Tech Management wave, Rally was named among the ten most significant portfolio management software providers, and was the only Agile vendor featured in the report. The inclusion of a pure Agile vendor reflects the growing importance of executing portfolio plans faster to hit critical market windows.

In midsize to large organizations, delivering business value faster requires scaling Agile practices to coordinate a large number of teams to deliver on an entire portfolio scope. But a good strategy is irrelevant if you can’t deliver on it in the timeframe required to stay competitive. As companies realize this, faster portfolio execution becomes an imperative.

At the same time, many of these companies still have traditional financial controls that impede their ability to respond to market changes: project funding that locks in requirements for long periods of time and mandates that developers leave their environments to fill out timesheets — a process that often results in inaccurate cost reporting.

Changing those financial practices takes time — and you can’t afford to wait. If you work in one of those organizations, you can still scale your Agile practices to deliver faster by integrating the Rally platform with PPM vendors.

Planview — one of the leading PPM vendors — has been honing its integration with the Rally platform for several years to create a realtime connection between traditional portfolio planning and Agile portfolio execution. The latest Rally-Planview integration provides added granularity into the visibility of Agile projects from PPM dashboards. When adopting Agile, the more visibility you can give to business leaders, the faster they can adapt their plans to respond to changes.

The Forrester report recognized Rally for its software integrations with several PPM vendors. To learn how you can accelerate your portfolio execution, take our portfolio management tour.

Catherine Connor
Categories: Companies

Thinking About Estimation

Johanna Rothman - Tue, 04/21/2015 - 16:06

I have an article up on agileconnection.com. It’s called How Do Your Estimates Provide Value?

I’ve said before that We Need Planning; Do We Need Estimation? Sometimes we need estimates. Sometimes we don’t. That’s why I wrote Predicting the Unpredictable: Pragmatic Approaches for Estimating Cost or Schedule.

I’m not judging your estimates. I want you to consider how you use estimates.

BTW, if you have an article you would like to write for agileconnection.com, email it to me. I would love to provide you a place for your agile writing.

Categories: Blogs

February Dallas Recap: Discover the Power of Pair Testing

DFW Scrum User Group - Tue, 04/21/2015 - 15:28
In February, we were fortunate to have DFW Scrummer Pradeepa Narayanaswamy present at our Dallas meeting. Agile teams are expected to deliver high quality product, and team members become more cross-functional and take ownership of quality. To address scarce testing … Continue reading →
Categories: Communities

Knowledge Sharing


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