Skip to content

Feed aggregator

Major SAFe LSE Update with Big Implications

Agile Product Owner - Thu, 05/14/2015 - 16:11

Hello Folks,

We readily admit that this hyper Agile-innovation-do-your development-work-in-the-public-domain business model of ours can make for an interesting journey of discovery for all involved. Working closely with our community of practice, we’ve devoted the last several months to the development and conceptualization of the next generation Framework(s). There have been some amazingly informative and thought-provoking ah-ha! moments that have brought to us to where we are today, and we’d like to share the high points, and bring you up to speed on what we know about the next version of SAFe and SAFe LSE.

As you know, in response to the the needs of the large-scale complex systems builders, we’ve been developing a specialized framework, SAFe for Lean Systems Engineering (SAFe LSE, 77 versions of the big picture to date!). This work is representative of a diverse group of contributors, including Harry Koehnemann, systems engineering consultant from 321 Gang, as well as some deep engagement client work, and feedback from our SPC community in various forums. SAFe LSE went live as Preview One in early March.

As part of this effort, we went back to the fundamental principles of Lean-Agile development, and conceived the SAFe Lean-Agile Principles. We took care to make sure they were consistent and usable in both SAFe and SAFe LSE, because, well… they are the universal principles of Agile and Lean. The fact that they are the same was a small awakening (hmm…maybe the implementations aren’t all that different either). And so on we went to elaborate LSE.

On April 14, we (Dean, Harry, Alex, Inbar and Tim) delivered the inaugural course of the 3+1 day Applied SAFe for Lean Systems Engineering to a full house of about 40 Lean-Agile change agents from some of the world’s largest companies engaged in building some really big systems. Interestingly, about half of the attendees were SPCs already, and many of them had significant SAFe 3.0 rollouts in process.

The class was based on a new and improved structure and pedagogy we defined for the upcoming release of the next version of Leading SAFe (more on that in a future post). The class flowed really well and the response was very positive. The focus on the coordination necessary at the new System level, pre- and post-PI Planning, Lean-Agile Principles, Fixed and Variable System Intent, Enablers, Adaptive Requirements and Design, MBSE, Set-Based Design, etc. are all relevant in that world (as should be the case, since it was designed for that purpose). But there was some enlightening and critical feedback as well. Comments went something like this:

  • “Don’t worry about making the role titles suit our context. For example, we’ve already been retraining people to the more outward-facing, and more agile responsibilities of the Product Manager, so don’t change that back to ‘Lead Engineer’ just to make us more comfortable.”
  • “Yes, we have big challenges, but don’t make the new framework any less Lean-Agile. We need a strong vector, like SAFe, to keep us moving forward on our Lean-Agile path. Don’t water anything down for us.”
  • “We need a portfolio treatment for our system, but linking to another framework (SAFe 3.0), with a different big picture and different terms, etc. is well, pretty hokey.”
  • “We need this new extended content, but we are already rolling out SAFe, so two frameworks is not going to be helpful (in the least).”
  • “Most of our programs need that full system integration layer, but we have smaller programs too, and LSE looks a little too complex for those cases. Could you make it more modular?”

Well, you can imagine the interesting weekend we had digesting that feedback.

The very next week, Alex and I taught an SPC class in Boulder, based on SAFe 3.0. On Friday, as is our custom, we gave the new SPCs a preview of the future and walked them through SAFe LSE and the then-current plans for SAFe 4.0. Wow, what a lesson learned that was! Here are some relevant comments:

  • “Wait, we are building a big solution too, even though it is pure software, and we need that LSE ‘System’ level. Some of us may not think of it as a single system per se, but we routinely have to coordinate these activities. The current coordination article in SAFe 3.0 is helpful, but it doesn’t describe, for example, pre-and post- PI planning at the Value Stream level, System Intent, Adaptive Requirements, etc. And by the way, we think the treatment of Enablers is a much richer surface to discuss various types of enabling activities, like infrastructure—not just spikes and architectural features.”
  • But also “Not everything we build is that big; can the framework be more modular so that we can have it both ways?”

And so it was that we came to a new plan, based on a clearer vision of how to best support both communities. Fast forward to the images below (click to enlarge). Imagine an Expand/Collapse tab on the right of a future Big Picture. You shouldn’t have to imagine too long, as we’ll be implementing this for the LSE community for this summer.

SAFe_LSE_Preview2_5                  SAFe_LSE_Preview2_5_collapse

The odds are awfully high that you are looking at the new prototype for SAFe 4.0. You can look forward to a public preview website late summer.

One framework. One certification path. One set of partners. More modular. More scalable.

Stay tuned!

—Dean, Alex, Harry, Inbar, Richard, and the Scaled Agile team

Categories: Blogs

The Shape of Your Portfolio

Leading Agile - Mike Cottmeyer - Thu, 05/14/2015 - 15:03

What is your capability model showing you?

In the world of Agile Software development, capability model may not be a term commonly used. We often think of Agile as describing how the development teams function, standups, planning, demo, retro, much of the delivery world moves to the scrum rhythm. Capability model, now how does that fit into building better software?

A capability model is a graphical definition of what your organization does. In the most simplistic form, the model is an outline of business processes. Once the outline is created, the components of the outline can be assessed as to how they are valued and how they are performing for the business. Normally a portfolio team responsible for a line of business will assess the capabilities within their line of business. All of this analysis is just a pre-cursor to portfolio planning that will allow an organization to determine where should we invest in tools to support our business processes. The tool used to improve the performance of a business capability we are going to discuss is software.

So how do you get your capability model to help you decided where to focus your software dollars? And what does that focus tell you about your current portfolio? Lets look at how a Value/Performance matrix and Suitability/Pace of Change Matrix can facilitate the answers to the questions.

In the case of the capability analysis below the organization has defined their portfolio, as needed major improvements to Architecture. This portfolio team agrees that to grow or exploit business capabilities the underlying software architecture needs a major improvement. The shape of the portfolio is helping to communicate where there will not be an influx of new features but that new tools and software will improve capabilities.

Capability 1

For a similar business capability Model but Architecture that can support new features the Architectural Model below helps to communicate that most of the investment will result in new features and may have an impact on organizations other than Software.

Capability 2

In a mature architecture, that is well suited and aligned to business priorities, most of the change in the system will be defined as small enhancements. This allows the rest of the organization to consume change in small chunks so investments in training should be minimal.

Capability 3

Portfolio planning helps the organization to align software delivery to business priorities and predict the impact of software changes. The capability model combined with software architectural matrix is a valuable communication tool.

The post The Shape of Your Portfolio appeared first on LeadingAgile.

Categories: Blogs

10 Agile Quotes From The World’s Most Brilliant Minds

Agile Management Blog - VersionOne - Thu, 05/14/2015 - 14:29

Truly embracing agile can be a very hard task; agile practices are mostly learned and experienced, not something that you can easily glean from a book or article. But if you’re in search for valuable agile quotes to inspire you and your teams, here are 10 from the world’s most brilliant minds.

Brilliant Agile Quotes










1) “Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning.”
– Albert Einstein

As agile organizations, teams and team members, we must constantly question what could be better in order to continually improve.










2) “Perfection is not attainable, but if we chase perfection we can catch excellence.”
-Vince Lombardi

Perfection is a fallacy that leads to over planning, procrastination and failure to ship; agile is about focusing on delivering the best thing possible in a set time period.









3) “Unless someone like you cares a whole awful lot, nothing is going to get better.
It’s not.”
– Dr. Seuss

Agile practices focus on giving teams and individuals ownership of their work and accountability to the team and organization, so that you can care to make things better.










4) “Service to others is the rent you pay for your room here on earth.”
– Muhammad Ali

Service leadership and selflessness are foundation principles of agile; these are the prices to be paid to be part of an agile team.










5) “You simply have to put one foot in front of the other and keep going. Put blinders on and plow right ahead.”
– George Lucas

Agile is about doing as opposed to being paralyzed by over-planning; in agile you get the minimal necessary requirements and start working.










6) “It does not matter how slowly you go as long as you do not stop.”
– Confucius

A core principle of agile is working at a constant pace, which in turn enables you to deliver at a constant pace, as opposed to working sporadically and delivering nothing.










7) “We may encounter many defeats but we must not be defeated.”
– Maya Angelou

You will inevitably run into challenges along your agile journey, the key is to learn from these challenges and overcome them through standups and retrospectives.










8) “Intelligence is the ability to adapt to change.”
– Stephen Hawking

Agile is all about adapting to change; it was built on the foundational principle that business drivers will change and the development teams must be ready to adapt.










9) “Our greatest weakness lies in giving up. The most certain way to succeed is always to try just one more time.”
– Thomas A. Edison

In agile as in life there will be hiccups, but the iterative nature of agile makes it easy to do a retrospective and learn from our mistakes then move on to the next sprint and do better.










10)”If you can dream it, you can do it.”
– Walt Disney

We should never forget that agile was formed to find a way to develop software better and to more easily conquer our dreams.

What is your favorite quote as it relates to agile?

Categories: Companies

Agile Coach Camp

Leading Answers - Mike Griffiths - Thu, 05/14/2015 - 04:42
Leading Answers is a proud sponsor of Agile Coach Camp - West 2015, an Open Space Conference to be held in Calgary, Alberta on the weekend of June 12-14, 2015. I would like to invite my fellow agile practitioners to... Mike Griffiths
Categories: Blogs

"Taylorism"? I don't think that means what you think it means...

There's a tendency for people in the Agile community to throw around the word "Taylorism" as a synonym for evil.

It's worth remembering how work was seen before Taylor and "scientific management":
  • Work is not worthy of study
    • If you miss quota, you're incompetent... dock pay; if you beat quota, you must have been sandbagging previously... dock pay
  • No rest breaks
  • Workers are all the same
  • Improvements only benefit owners
Some of the ideas advocated by Taylor were significant improvements:
  • Work is worthy of scientific study
  • People should get rest breaks; fatigue exists!
  • People are different, which means some will be better suited for some work over others
  • Workers should benefit from improvements, not just owners
The problem with Taylorism really comes down to one assumption, that workers are lazy and dumb which means managers need to design how they work.

This is the key difference between Taylorism and Toyotaism (aka Lean):
  • Taylorism: Managers are the scientists
  • Toyota / Lean: The people doing the work are the scientists
Categories: Blogs

R: ggplot – Displaying multiple charts with a for loop

Mark Needham - Thu, 05/14/2015 - 02:17

Continuing with my analysis of the Neo4j London user group I wanted to drill into some individual meetups and see the makeup of the people attending those meetups with respect to the cohort they belong to.

I started by writing a function which would take in an event ID and output a bar chart showing the number of people who attended that event from each cohort.

We can work out the cohort that a member belongs to by querying for the first event they attended.

Our query for the most recent Intro to graphs session looks like this:

graph = startGraph("")
eventId = "220750415"
query =  "match (g:Group {name: 'Neo4j - London User Group'})-[:HOSTED_EVENT]->
                (e {id: {id}})<-[:TO]-(rsvp {response: 'yes'})<-[:RSVPD]-(person) 
          WITH rsvp, person
          MATCH (person)-[:RSVPD]->(otherRSVP)
          WITH person, rsvp, otherRSVP
          ORDER BY, otherRSVP.time
          WITH person, rsvp, COLLECT(otherRSVP)[0] AS earliestRSVP
          return rsvp.time, earliestRSVP.time,"
df = cypher(graph, query, id= eventId)
> df %>% sample_n(10)
      rsvp.time earliestRSVP.time
18 1.430819e+12      1.392726e+12 130976662
95 1.430069e+12      1.430069e+12  10286388
79 1.429035e+12      1.429035e+12  38344282
64 1.428108e+12      1.412935e+12 153473172
73 1.429513e+12      1.398236e+12 143322942
19 1.430389e+12      1.430389e+12 129261842
37 1.429643e+12      1.327603e+12   9750821
49 1.429618e+12      1.429618e+12 184325696
69 1.430781e+12      1.404554e+12  67485912
1  1.430929e+12      1.430146e+12 185405773

We’re not doing anything too clever here, just using a couple of WITH clauses to order RSVPs so we can get the earlier one for each person.

Once we’ve done that we’ll tidy up the data frame so that it contains columns containing the cohort in which the member attended their first event:

timestampToDate <- function(x) as.POSIXct(x / 1000, origin="1970-01-01", tz = "GMT")
df$time = timestampToDate(df$rsvp.time)
df$date = format(as.Date(df$time), "%Y-%m")
df$earliestTime = timestampToDate(df$earliestRSVP.time)
df$earliestDate = format(as.Date(df$earliestTime), "%Y-%m")
> df %>% sample_n(10)
      rsvp.time earliestRSVP.time                time    date        earliestTime earliestDate
47 1.430697e+12      1.430697e+12 186893861 2015-05-03 23:47:11 2015-05 2015-05-03 23:47:11      2015-05
44 1.430924e+12      1.430924e+12 186998186 2015-05-06 14:49:44 2015-05 2015-05-06 14:49:44      2015-05
85 1.429611e+12      1.422378e+12  53761842 2015-04-21 10:13:46 2015-04 2015-01-27 16:56:02      2015-01
14 1.430125e+12      1.412690e+12   7994846 2015-04-27 09:01:58 2015-04 2014-10-07 13:57:09      2014-10
29 1.430035e+12      1.430035e+12  37719672 2015-04-26 07:59:03 2015-04 2015-04-26 07:59:03      2015-04
12 1.430855e+12      1.430855e+12 186968869 2015-05-05 19:38:10 2015-05 2015-05-05 19:38:10      2015-05
41 1.428917e+12      1.422459e+12 133623562 2015-04-13 09:20:07 2015-04 2015-01-28 15:37:40      2015-01
87 1.430927e+12      1.430927e+12 185155627 2015-05-06 15:46:59 2015-05 2015-05-06 15:46:59      2015-05
62 1.430849e+12      1.430849e+12 186965212 2015-05-05 17:56:23 2015-05 2015-05-05 17:56:23      2015-05
8  1.430237e+12      1.425567e+12 184979500 2015-04-28 15:58:23 2015-04 2015-03-05 14:45:40      2015-03

Now that we’ve got that we can group by the earliestDate cohort and then create a bar chart:

byCohort = df %>% count(earliestDate) 
ggplot(aes(x= earliestDate, y = n), data = byCohort) + 
    geom_bar(stat="identity", fill = "dark blue") +

2015 05 13 00 30 59

This is good and gives us the insight that most of the members attending this version of intro to graphs just joined the group. The event was on 7th April and most people joined in March which makes sense.

Let’s see if that trend continues over the previous two years. To do this we need to create a for loop which goes over all the Intro to Graphs events and then outputs a chart for each one.

First I pulled out the code above into a function:

plotEvent = function(eventId) {
  query =  "match (g:Group {name: 'Neo4j - London User Group'})-[:HOSTED_EVENT]->
                (e {id: {id}})<-[:TO]-(rsvp {response: 'yes'})<-[:RSVPD]-(person) 
          WITH rsvp, person
          MATCH (person)-[:RSVPD]->(otherRSVP)
          WITH person, rsvp, otherRSVP
          ORDER BY, otherRSVP.time
          WITH person, rsvp, COLLECT(otherRSVP)[0] AS earliestRSVP
          return rsvp.time, earliestRSVP.time,"
  df = cypher(graph, query, id= eventId)
  df$time = timestampToDate(df$rsvp.time)
  df$date = format(as.Date(df$time), "%Y-%m")
  df$earliestTime = timestampToDate(df$earliestRSVP.time)
  df$earliestDate = format(as.Date(df$earliestTime), "%Y-%m")
  byCohort = df %>% count(earliestDate) 
  ggplot(aes(x= earliestDate, y = n), data = byCohort) + 
    geom_bar(stat="identity", fill = "dark blue") +

We’d call it like this for the Intro to graphs meetup:

> plotEvent("220750415")

Next I tweaked the code to look up all Into to graphs events and then loop through and output a chart for each event:

events = cypher(graph, "match (e:Event {name: 'Intro to Graphs'}) RETURN ORDER BY e.time")
for(event in events$n) {

Unfortunately that doesn’t print anything at all which we can fix by storing our plots in a list and then displaying it afterwards:

p = list()
for(i in 1:count(events)$n) {
  event = events[i, 1]
  p[[i]] = plotEvent(as.character(event))

2015 05 14 00 57 10

This visualisation is probably better without any of the axis so let’s update the function to scrap those. We’ll also add the date of the event at the top of each chart which will require a slight tweak of the query:

plotEvent = function(eventId) {
  query =  "match (g:Group {name: 'Neo4j - London User Group'})-[:HOSTED_EVENT]->
                (e {id: {id}})<-[:TO]-(rsvp {response: 'yes'})<-[:RSVPD]-(person) 
            WITH e,rsvp, person
            MATCH (person)-[:RSVPD]->(otherRSVP)
            WITH e,person, rsvp, otherRSVP
            ORDER BY, otherRSVP.time
            WITH e, person, rsvp, COLLECT(otherRSVP)[0] AS earliestRSVP
            return rsvp.time, earliestRSVP.time,, e.time"
  df = cypher(graph, query, id= eventId)
  df$time = timestampToDate(df$rsvp.time)
  df$eventTime = timestampToDate(df$e.time)
  df$date = format(as.Date(df$time), "%Y-%m")
  df$earliestTime = timestampToDate(df$earliestRSVP.time)
  df$earliestDate = format(as.Date(df$earliestTime), "%Y-%m")
  byCohort = df %>% count(earliestDate) 
  ggplot(aes(x= earliestDate, y = n), data = byCohort) + 
    geom_bar(stat="identity", fill = "dark blue") +
    theme(axis.ticks = element_blank(), 
          axis.text.x = element_blank(), 
          axis.text.y = element_blank(),
          axis.title.x = element_blank(),
          axis.title.y = element_blank()) + 
    labs(title = df$eventTime[1])
2015 05 14 01 08 54

I think this makes it a bit easier to read although I’ve made the mistake of not having all the charts representing the same scale – one to fix for next time.

We started doing the intro to graphs sessions less frequently towards the end of last year so my hypothesis was that we’d see a range of people from different cohorts RSVPing for them but that doesn’t seem to be the case. Instead it’s very dominated by people signing up close to the event.

Categories: Blogs

Embracing the Hybrid

Leading Agile - Mike Cottmeyer - Wed, 05/13/2015 - 14:59

Ten years ago(ish) I found myself on the wrong end of an intervention. A group of developers I had a lot of respect for cornered me in one of those fishbowl offices at a client site. You know the ones – glass on all sides… They sat me down in a small chair and stood around me. It was weird.

Intervention“Listen dude, we need to have a talk. This waterfall crap… it has to stop. We’ve proven that it doesn’t work” (Note – these guys always seemed to use “We” as a kind of vague reference meaning “everyone in the entire universe… except you”.

They went on “You need to lean about Agile.” (Yeah, this did actually happen.)

The backstory is, we were all on a team together, all working on a project. In retrospect, what I think they meant was “We want to do Agile.” But whatever… I had respect for these guys, had enough awareness to know Agile was creeping in around the edges and that despite my previous traumatic experiences, it was something I was not going to be able to avoid forever. And so, I began my journey to the Wudang Mountains to learn the Way of the Agile.

The Quick and the Dead

Back then; there were basically two kinds of people… the Agile, and the non-Agile. If that doesn’t make sense, you can think of them as the enlightened mindful beings who have stepped out of Plato’s cave and the poor bastards who are too addicted to their pain to leave the misery of darkness.

For many years the fight for Agile was all about transformation. And by transformation, we meant that you recognized the one true god of Agile, embraced the manifesto and started shaking your head at those silly little rabbits who just hadn’t found THE WAY yet.

As a PM, it was a weird time. After having spent the better part of 10 years trying to master traditional PM techniques, I was suddenly in a world where not only did I not understand how things worked, but where I was walking around with the scarlet letters PMP on my chest. I hid those letters from the Agile people as best I could, convinced that at any moment I’d be discovered and out-ed as PMP who had infiltrated the Agile party.

Showing Transformation the Door

Pinocchio_1940Over the past two years, something has begun to shift – both in and outside of Agile. Things are a bit less polarized. I run into less PMPs trying to convince me that waterfall is “just really fast Agile”, less Agile people who want to ship the waterfall off to leper colony that will (obviously) never actually deliver, and less of those intimidating Lean guys who look down upon the Scrum people like they rode to school on the “special bus”. Even the word “transformation” seems to have been discovered by the bouncers. They’ve been polite about it, but clearly that word has been asked it to finish its drink and move towards the door. The word “transformation” IMHO, scares people a bit because for a while there was this perception that you’d become Agile… like it was this thing that would happen to you… and then Pinocchio would become a real boy.

For better or worse, people seem to have discovered it doesn’t always work like that. When an organization adopts Agile, it’s sort of like when someone decides to get in shape. You may put in a lot of time and effort and reach the stage where you can acknowledge that your goals have been achieved and you are “in shape” (or “Agile”). But, the only way to maintain this is to keep pushing harder and harder each day, and there is no real end point. Becoming Agile is not something you finish… It is a continual journey.

If you’ve ever spent any amount of time in a gym, you know there are always going to be model examples of physical magic with 7% body fat. They are there at all hours of the day or night. Sometimes it seems like they exist for the sole purpose of crushing your self-esteem and making you feel like you MUST WORK HARDER. We have equivalents to that in Agile too.

The Digital PM Revolution

On the other side of the hall is a completely different party. These are the Digital PMs. They are younger, possibly a little more open-minded than the Waterfall or Agile people. They consume new tools and practices like they were shot gunning beers. The pace at which they adopt and shift <cough>”pivot”</cough> can make even the Agile folks a little dizzy. What’s worse (or better) is that they never sit around debating whether something is Agile or not. They really don’t seem to care. They just want stuff that works and they are totally happy mixing up their process Garanimals to get to something that helps them survive the day and serve the client.

It has been awhile since I’ve been asked to join a waterfall vs. Agile debate. It’s been awhile since anyone really seemed to care much about that (because now they are more focused on “outcomes”). But, in the same way that each of us reaches a point in our gym rat phase where we think, “where I am now is good enough, I’d like to just maintain this”, and the DPMs have found a way to live in a world that straddles the line between Agile and waterfall. Perhaps the hybrid model is going to emerge as a viable alternative that can stop being a milestone and become an actual destination.

“Scrum, but” has been around for a long time, always discussed with shame – like it was a stage people were trying to get through. Now that we’ve reached a point where the organizations who were going to have an easy time making the switch have done so, we’re focused on the ones who have a harder time with the change. For some of the larger organizations it can be tough for them to just turn on a dime and get their Agile on.

helloHello, My Name Is Hybrid

My personal theory  is that once we reach a point where we acknowledge/decide that the hybrid is going to be here and that this is an okay thing, that we’re going to see a major shift in the focus of thought leaders. You can see evidence of this already as they start to try to come up with tools/practices to let them measure waterfall and Agile projects in the same portfolio. What I think we are going to see emerge is patterns of practices and formulas for difference orgs to try out and adapt to get to better, quicker delivery (outcomes). When this happens, and begins to spread, Agile will stop being something we do, and become something we are.

And maybe (hopefully) no one will care about Agile, waterfall or hybrid at all – as long as we’re delivering.

The post Embracing the Hybrid appeared first on LeadingAgile.

Categories: Blogs

Slow… or Just Observant?

Evolving Excellence - Wed, 05/13/2015 - 08:38

kathmandu-durbar-beforeBy Kevin Meyer

The recent earthquake in Nepal has led me to reflect a bit on the importance of observation.  Just over a year ago my wife and I were in Nepal, visiting various locations in the Kathmandu valley as well as Pokhara and Begnas Lake.  It's a beautiful country with a beautiful people that work hard every day to scratch out a living.

kathmandu durbar square earthquakeWe got to see many of the numerous UNESCO World Heritage Sites in the country, including Durbar Square in Kathmandu.  I'm glad we did - here's the photo we took, and what it looks like now after the earthquake.  A heartbreaking loss of culture, architecture, and history.

We went, we observed, we learned the other stories, and, as often happens on our travels to what are now over 60 countries, we were humbled.

I have a long list of places I still want to see, and the earthquake in Nepal has added a sense of urgency lest something similarly unfortunate happens.  One of our other favorite places, Puerto Varas in southern Chile and across the Lakes Passage to Bariloche in Argentina, is currently dealing with the Calbuco volcano.

But urgency can be dangerous, especially to observation.

When I was first starting my career someone told me to "walk with purpose" - strong and quick.  It projected authority and created confidence.  Who knows, perhaps it did help.  I rushed here and there, and climbed the ladder.   The years flew by, never to be experienced again.

Then one day I learned about the Ohno Circle and I paused.  I stood, watched, and learned.  I realized how much I was missing by moving quickly.  I began to move slower, taking care to observe.  I also began to plan observation.  What was I going to observe?  How?  What is the problem or purpose?  What would I do with what I learned?

Outside of work I soon developed a habit that has become my favorite daily activity: a nice slow kinhin - walking meditation - on the beach a couple blocks from my house.  One step per breath, slow and deliberate. It's amazing what you notice - both about your surroundings and about yourself.

According to my wife I also began to drive slower or, in her words, became a "grandpa driver."  Is there truly a rush?  Usually not.  We're just socially predispositioned to want to go fast, to compete, regardless of necessity.  What are you missing?  You may not know.

So think about that slow driver ahead of you, causing you to speed and swerve and bolt ahead to probably just meet again at the next stop light.

Is he old and senile, or happy and aware... and observing?  Ok, from the swerving he might be old and senile.  Maybe.  Or maybe it's me.  Slow down and observe, otherwise you might think you've arrived but not know where you've been.

Categories: Blogs

Agile Australia, Sydney, Australia, June 17-18 2015

Scrum Expert - Wed, 05/13/2015 - 07:40
Agile Australia is a two-day conference built specifically for Australian Agile and Scrum practitioners who are serious about expanding their thinking and ways of working: at an individual and organizational level. Hear valuable insights from highly regarded keynotes, learn how to create high-quality solutions faster, and network with potential clients and collaborators. In the agenda of Agile Australia you can find topics like “Intent-based Leadership”, “Myths and patterns of organisational change”, “Simplicity by Design”, “Achieving tangible business benefits with the Scaled Agile Framework”, “Autonomy and Leadership at Spotify”, “Concrete experimentation in ...
Categories: Communities

Command / Direction vs Leadership vs Management

Modified from The Art of Action,

"Command" or "Direction": What do we have to do and why? (intellectual)

"Leadership": We are willing to commit to this (emotional)

"Management": We have the skills and resources to do this (logistics)
Categories: Blogs

Frustrated? It is probably your fault.

Thought Nursery - Jeffrey Fredrick - Tue, 05/12/2015 - 23:50

That’s the title of my talk which has been accepted to the program for the upcoming Devopsdays Amsterdam June 24th, 25th and 26th. The topics I’ll be discussing will be familiar to the attendees of the London Action Science meetup — and to the people who have been diligently reading my session notes — which is that if you want to create change you need to start by changing your behaviour.

For the past few CITCONs I have been leading open space sessions with a very similar theme: “Can’t create change? It is probably your fault”. Those sessions have been great fun, because we get to talk through situations in real time together. My challenge now is how to generate those same kind of ah-ha moments for the audience without building it together in the room.

I’m not sure how I’ll do that yet, but I’m excited to have been accepted and to have the opportunity to give it a go. Hope to see you there!

Categories: Blogs

Customer Spotlight: QSR International

Rally Agile Blog - Tue, 05/12/2015 - 21:30

Sharing stories about Rally customers who are doing cool and interesting things.

QSR International builds industry-leading software for qualitative research. Its flagship product, NVivo, helps policy makers, academics, and market researchers analyze large amounts of unstructured data to better understand human behaviors and motivations.

I recently spoke with the company’s CTO, Adam Long, about how QSR International is pushing the limits of what’s possible in the qualitative research field.

“We’re building things customers don’t yet know they need.”

For Long’s R&D teams based in Melbourne, Australia, there’s an increasing amount of uncertainty in the development process. They’re aiming to identify opportunities that no one — not even customers or competitors — has yet articulated. But doing so calls for a more experimental approach.

That’s not to say the R&D teams were lagging. Using traditional waterfall processes, they were delivering with high predictability and quality (it turns out they had room for quality improvements, but more on that later). And their customer collaboration and feedback loops are effective and mature — incorporating usability workshops, surveys, beta programs, and hack days. But they started to wonder whether they were building the hardest-hitting features and if they could deliver faster.

Getting Unstuck from Conventional Thinking

Meanwhile, Long was spending a lot of time thinking about innovation, toying with the idea of using cross-functional teams and Agile practices. In 2013, the R&D teams started adopting a faster release cadence, but couldn’t quite move the needle toward full Agile adoption. When Rally started working with QSR International in 2014, the teams had spent a year stuck between two methodologies ... and were ready to get unstuck.

The Agile Transformation Pays Off

Fast forward a year, and QSR International has rolled out the Scaled Agile Framework® (SAFe®) across its four teams, using the Rally platform to plan at the portfolio, program, and team levels.

The group has seen an 85-percent drop in user-reported defects through HockeyApp — a benefit Long didn’t expect since they were doing a pretty bang-up job to begin with. In addition, the teams have gained focus and clarity, with better collaboration and a renewed sense of ownership. That means they’re prioritizing features that will have the greatest impact in the market — and they’re doing it faster, which is critical in maintaining the company’s leadership position.

QSR International’s story provides a great example of how perseverance can pay off in an Agile transformation, and how a strong executive vision can clear a path toward sustainable innovation. We can’t wait to see where QSR International goes next.

Read the case study.

Jen Page
Categories: Companies

Agile Assessment

TV Agile - Tue, 05/12/2015 - 18:56
Derek Morrison, Head of Product at Tesco PLC, who will share his thoughts on Agile Assessment. The talk entails Agile assessments, as part of: 1) an Agile transformation program 2) recruitment processes 3) the professional development of your Agile workers 4) team development Video producer:
Categories: Blogs

From 3 Scrum Teams to a Single Kanban Team

Scrum Expert - Tue, 05/12/2015 - 18:45
This talk is a study of a case in which three Scrum teams converged into a single large team Kanban system design. Working in separate teams resulted in issues with responsibility, hand-overs, resource utilization and a culture of blaming others. In a large, highly self-organized team the members could share responsibility for the whole, work on the right things and focus on flow. This talk concretely demonstrates the Kanban system, its design principles and its evolution. Participants can expect to learn from a successful, but unorthodox real-life story, to possibly ...
Categories: Communities

Why Physical Task Boards Still Matter

Leading Agile - Mike Cottmeyer - Tue, 05/12/2015 - 14:44

If your agile teams are not using physical task boards, you don’t have all the context

That’s the theory I put forth to you today. My theory is based on the June 2014 Journal of Psychological Studies article entitled “The Pen is Mightier Than the Keyboard – Advantages of Longhand Over Laptop Note Taking.”

The debate of pen & notepad vs. keyboard & laptop is not a new one. Past studies have been done on the effects of multi-tasking (and the lure thereof) with laptops. There have also long been theories, based on understanding of brain science, that the human brain stores electronic data differently than it does written data and that the written data is stored in a way that is easier to access again.

However, Dr. Mueller and Oppenheimer’s study specifically tested the results of using offline laptops, specifically to just take notes, against longhand written notes. I’m not going to rehash all the data here. For a good article outlining how the study was conducted go to Fast Company and you can download the entire paper at

The key points are:

  • When it is important to form a deeper understanding of the material, take written notes.
  • Even when you have the full type written data to study, you will do worse on tests both on factual and contextual data.
  • This can apply to task as well, as Mueller states in the Fast Company article.
Connecting this to Agile

Based on this study and my own years of reflection on this (I stopped using laptops for notes back in 2010) I believe this explains why teams who use both a physical task board and an electronic one (Rally, VersionOne, AgileCraft, etc.) do better than those who just use the online tool.

Don’t get me wrong, I’m not saying get rid of the online tool. I absolutely believe an online tool is useful when dealing with anything more than the smallest agile programs. What I’m saying is, while counter intuitive and seeming to cause more work, having a physical task board in addition to your online tool can be a big boost on your way to becoming a high performing agile team. It is not unlike the seeming disconnect of pair programing being more efficient than parallel programing. The added work of keeping two boards is minimal compared to the benefits of making your team more effective and delivering better final product.


When doing your release and sprint planning, do it all with old-fashioned cards, blue tape and pens. When you’re done, someone takes all that and puts it into the online tool and then it gets up on the physical task board. During the daily standups, keep the laptops closed and move stories and tasks on the physical board. At the end of the meeting someone (cough… Scrum Master) can update the online tool. The benefits will be worth the little extra work.

  • Technology doesn’t get in the way: No one is hiding behind a computer during planning. No worries about connections, projectors and so on.
  • The act of writing and collaborating together will create a greater joint understanding.
  • A week into the sprint, when you look at the User Story, you will remember the whole context and that while the PO forgot to update the acceptance criteria, you remember he wanted this story to work on Android and iOS not just iOS.
  • There is nothing more satisfying than physically grabbing a story card and moving it from Doing to Done. Celebrate the moment!
Real World Application

Having been in the longhand vs. laptop note taking debates for years I know it can be a hard concept to grasp that written notes are more effective. On this count I can speak only from first hand experience. When I review written notes I can visualize the meeting. I can remember who was sitting where, who was giving who sidelong glances and more.

When it comes to teams and physical boards, I’ve also seen it work. In one instance we had three Scrum teams who were struggling with their transition. After suggesting physical boards on top of their online tool, two of the three teams saw a marked increase in effectiveness and decrease in churn around acceptance and quality. The third team didn’t put in a physical board and while they had a lot of contributing factors, the lack of the board is one of the reasons I believe they failed.

In another experience our general manager was very hands on with the division. He was also a very classic “too busy” executive. While he had full access to all our information, he never had time to look at it. The physical board was in a high traffic hallway on the way to his office. He knew exactly what was happening at all times and this in turn led to him being less hands on not more.

And lest I seem overly biased (I am), in a recent article in the Wall Street Journal IBM’s CIO Jeff Smith was observed:

He also makes use of physical, visual tools such as storyboards. He found that the signs and sticky notes that characterize Agile workspaces work best if they remain in the physical world, not the digital one.  After some experimentation, he found that the physical signs gave people a place to go, and that gathering point fostered more group learning. – CIO Journal

Distributed Teams

A colleague rightly pointed out that I hadn’t touched on this third rail. We can’t deny that in most enterprises having all your teams in one place is pretty much impossible. Even getting a seven to nine person team in one place can be a challenge. So isn’t the physical board only a niche player when the stars align and your team is all in one place?

Yes and no.

First off, the agile community has long recognized that colocation is rarely practical. Over the last few years the recommended advice of colocation has moved from “all” to “team”. It is a lot easier to have a seven-person team in one place than it is seven full teams. When you can get your team in one place, the physical board is still of value to them, just not as much to the larger organization.

When the team is truly distributed, then the physical board starts to lose value. If you have most of your team in one place, the board can still be used. You just have to engage some process and remote technology to keep the remote team members in the know. These are classic distributed team tools, so I won’t dive too deep. Get your teams together for major release planning. Have a web cam pointed at the physical board and burn down. Take hi-res pictures and send them to the remote team members.

And IBM CIO, Jeff Smith? His organization is 20,000 strong. Pretty sure they are not all in one room.


Don’t get rid of your online tool, that’s critical for enterprise organization. However, do grab a chunk of wall space and use your blue tape to create a physical board. You can be even more productive and generate a better, finished product.

Don’t take my word for it, try it for a sprint or two and see what the retrospective says.

The post Why Physical Task Boards Still Matter appeared first on LeadingAgile.

Categories: Blogs

Why Agile Won’t Make You More Productive

Agile Management Blog - VersionOne - Tue, 05/12/2015 - 14:15

PrintAccording to the 9th annual State of Agile™ survey, more organizations are adopting agile in order to improve productivity:

“Consistent with last year, most respondents adopted agile practices to accelerate product delivery (59%) or enhance their ability to manage changing priorities (56%). However, in 2014, productivity (53%) has moved into the top 3, outranking last year’s #3 response – improved IT and business alignment.”

This made me wonder why there is a perception that if companies transition to agile, teams will be more productive. I put my waterfall hat on and read the twelve principles that support the Agile Manifesto from a traditional stance. I could see where delivering working software frequently and at a sustainable pace speaks to teams being more productive in agile.

For example, a project that is managed with a traditional waterfall process has big upfront design and is transitioned over to a team that knows they have six to nine months to produce the software. At the beginning of project, the teams are more relaxed and moving slower. The intensity level and sense of urgency is a lot lower. Then as time goes on – three months, six months – the teams and management start to miscommunicate and stop being as diligent about status meetings. Near the end of the project suddenly the pressure and a bit of panic set in. Teams and management are panicking because now they have to scramble to get the software finished. Maybe this is what creates the perception with waterfall that your teams are not constantly producing software; there’s an ebb and flow.

Waterfall projects start out with very low intensity. By the end of the project the intensity is extremely high and teams are burned out because they’re working crazy hours. The teams are producing low-quality code because they have to rush and the code isn’t being tested. The low quality work damages the team’s pride, which decreases morale and can lead to turnover.

The benefit of going to agile is that the team maintains a constant level of intensity and consistent working hours, which in turn empowers the team to produce beautifully working software at a constant pace.

So when people are saying “productivity,” what I think they really mean is “intensity.” If we’re maintaining a constant level of working hours, a constant level of quality and a constant level of delivery, teams are happier, they’re proud of their work and they enjoy going to work. This is super important because keeping good developers is really difficult. If good developers aren’t happy they can easily leave and go somewhere else. That’s why 26% of respondents to the 9th annual State of Agile survey said improving team morale was the reason they adopted agile.

That’s my take on why there is a perception that agile is more productive than waterfall. When I saw the 9th annual State of Agile survey, I was curious about why people felt that if they moved to agile their teams were going to be more productive.

Why do you think there’s a perception that if companies go agile, teams will be more productive?

State of Agile is a trademark of VersionOne Inc.

versionone-coaches-susan-evansAbout the Author
Susan Evans

Susan has more than eight years of agile project management experience in software development. Prior to joining the company, she was an internal coach who optimized the usage of the VersionOne platform to help many non-collocated teams thrive in their agile processes. Susan focuses on enhancing team relationships, communication skills, conflict resolution, and processes to help create happy teams that deliver high quality.


Categories: Companies

June 17-18th in Sydney, Australia: Agile Australia 2015

James Shore - Tue, 05/12/2015 - 10:01
12 May 2015 James Shore/Calendar I'll be at Agile Australia in June!

I'm one of Agile Australia's keynote speakers this year. I'll be around for the entire conference, so look me up. Here's the blurb for my keynote:

The Reward

For an approach that emphasizes simplicity, success with Agile is surprisingly difficult. Some teams see amazing results. They're able to respond to changing needs, deliver new releases every day, and do so with nearly zero defects. Other teams complain that Agile makes things worse, not better. They get less done and spend more time in pointless meetings.

What is about Agile that creates such different experiences? Let's take a step back and look at what makes Agile work. What's the point of these Sprints, stories, Scrums, and other practices? What leads to success and what leads to struggle? It's time for a frank discussion about what it takes to succeed with Agile.

Agile Australia is in Sydney on June 17th and 18th. Sign up here.

I'm also teaching full-day workshops about coaching for best-fit Agile in Sydney and Melbourne, on the 16th and 19th respectively. You can learn more here.

Categories: Blogs

Umfrage: Best Agers und ihr berufliches Umfeld

Scrum 4 You - Tue, 05/12/2015 - 08:00

Ich habe eine These: Manager_innen im Alter 40+ müssen mehr und mehr leisten, gleichzeitig wird ihr Umfeld immer komplexer und alle wollen ständig mehr von ihnen. Das stresst.

Aber Thesen kann ich ja viele aufstellen. Daher haben wir uns mit der Hochschule Augsburg zusammengetan, um das Ganze etwas wissenschaftlicher anzugehen. Auf eine allgemeinere Ebene gebracht wollen wir wissen, wie ihr als erfahrene Führungskräfte mit den neuen Medien, den Leistungsanforderungen und den Veränderungen in der Arbeitswelt umgeht. Außerdem wollen wir herausfinden, wie die Zusammenarbeit zwischen den Generationen funktioniert.

Diese Studie soll unbedingt eine valide Aussage liefern und dafür brauchen wir mindestens 300 Teilnehmer_innen. Bitte helft uns dabei! Es sollte nicht mehr als 10 Minuten eurer Zeit beanspruchen.

Schnappt euch am besten gleich jetzt einen Kaffee und klickt euch durch den Fragebogen:

Selbstverständlich werden alle Angaben vertraulich behandelt und anonym ausgewertet. Das Ergebnis der Studie werden wir voraussichtlich im Laufe des Juli auf zur Verfügung stellen.

Vielen Dank für eure Unterstützung!

Categories: Blogs

One Language Resumes

Reviewing resumes as a manager, tech lead, or even just a developer is no one’s favorite activity. Resume’s are inefficient, misleading and so often boring. If you’re a prospective hire boring is bad.

A simple case is the standard corporate style J2EE developer resume. There are host of bullet points claiming skills I already expect them to have with 10+ years of development experience.

  • Spring
  • Hibernate
  • Tomcat, JBoss, Weblogic, or WebSphere
  • A smattering of design patterns from Singleton to Template Method
  • Javascript and some JQuery
  • Some selection of Java’s innumerable web frameworks.
  • Oracle/SQL Server/MySQL

At this point they’ve done nothing to distinguish themselves from the pile of already screened and rejected resumes beside them. You’ve developed on the JVM for 10+ years and you’ve never looked into alternative JVM languages. No Groovy, Scala, or Clojure. Not even some adventure off the JVM into Ruby, Go, Elixir, Python.

Java is by design a simple if verbose language with a huge amount of libraries and IDE tooling. It has never been the best solution for almost anything. Luckily there’s been a “Get out of Jail” free card option for a long time now. You can pull out a JVM language that better fits the problem space solve the problem more elegantly. All that and still produce compatible byte code and interop easily with existing Java libraries. It’s a career limiting to ignore that opportunity.

For the brave there’s always the option of leaving the JVM entirely and trying something like Ruby, Python or Go. It may require adjusting to life outside a familiar IDE or dealing with a new set of libraries, but it’s not a very difficult step to make.

So fair or not let me explain the conclusions I make when I see a J2EE developer resume with many years of experience and no mention of a second or third language experience:

  • Not very interested in learning in an engineering field that is constantly changing.
  • Did the majority of their learning by working on an existing Java codebase, and aren’t interested in spending any time coming up to speed on anything that isn’t currently required for the job.
  • Don’t enjoy development as a pursuit other than the fact that it’s fairly well compensated.
  • Are OK with doing things the hard way because they have one hammer in the toolbox.
  • Think they know a second language because they hack some javascript when required.
  • Copy and Paste is their most common approach to gaining code refuse.
  • Won’t be able to come up to speed quickly.
  • Are going to bomb out in a phone screen, so no point in scheduling one.
Categories: Blogs

All We Need To Do Is...

Agile Artisans - Tue, 05/12/2015 - 02:00

After Andy's article last week, many people (including quite a few I have an enormous amount of respect for, and many others I haven't met) announced that they much preferred to simply keep doing what they've been doing. One of the leaders in our industry said she preferred to "keep improving how we deliver value at sustainable pace". And you know what? She's right.

That's an idea… it's a great value. But it's only that: an intangible; which requires someone with a great deal of experience to correctly interpret and apply that advice. Someone who's been working with software for a while, and has invested the effort required to become skilled, understands exactly what she meant. The technical guru who has 10 years of experience (not 1 year repeated 10 times) can take this advice, and it's useful.

Unfortunately, in my experience, that describes very little of our industry. We do have a talented core of skilled individu

Categories: Companies

Knowledge Sharing

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