Skip to content

Feed aggregator

The Role of PI Objectives by Eric Willeke

Agile Product Owner - 4 hours 19 min ago

We are always grateful to the SPCs in the field who are transforming enterprises to a new and better Lean and Agile way of working with SAFe. It’s heavy lifting, but the results (see Case Studies, many more on the way): higher quality and productivity, faster time to market, higher quality of work life, are so worth it. Many of the SPCs are thought leaders in their own right, and contribute directly to the SAFe body of knowledge.

Eric Willeke from Rally is a good example. He recently opined on the critical role that the interesting mechanism of “PI Objectives” play in aligning the business and helping Agile Release Trains achieve better outcomes. His post is here: Role of PI Objectives in SAFe.

And a while back, he contributed another neat bit of work, highlighting how SAFe applies WIP limits, both explicitly and simplicity at the Portfolio level, where it really counts. Just for reference, that post is Perspective on SAFe Portfolio-WIP-Limits.

Both of these belong in Guidance, so I’ll talk to Eric and see if we can get that accomplished.

Thanks Eric!

Categories: Blogs

Summary of five years

Thought Nursery - Jeffrey Fredrick - 11 hours 57 min ago

“What have you been doing these last few years?” was the question Péter Halácsy asked me during my visit to Prezi. I was there to for the CTO equivalent of a developer exchange: learning how things were done at Prezi, sharing my observations, and then speaking at the Budapest Jenkins meetup. Prior to my visit Péter had come to this blog to learn more about me, only to learn that I’d not been blogging. I’m resolved to get back into the blogging habit this year and I decided I’d take the time to fill in the gap for any future Péters. In part this will recapitulate my LinkedIn profile but also describe some of what I felt was most significant.

The primary reason I only posted a single post after 2009 was that I joined Urbancode in a marketing/evangelism role and I posted almost everything I had to say under their masthead. In my two and half years there I had a great time spreading the word about build automation, continuous delivery and Devops. I was able to visit a wide range of companies, learn first hand about the challenges of enterprise organization, and then turn this information into new content. At Urbancode we developed a very good flow of information and almost every month we had a new webinar, a newsletter, and maybe a white paper. My primary content collaborator was Eric Minick and he has kept up those evangelizing ways at IBM following their acquisition of Urbancode.

After I left Urbancode we made a family decision to try living in London for a few years. I reached out to Douglas Squirrel and he brought me into TIM Group to do continuous delivery, infrastructure and operations. In my time there I’ve become CTO and Head of Product and I’ve really enjoyed the opportunity to apply what I know, both about product development and about organizational change. I’ve been almost equally as absent from the TIM Group development blog, but I have managed to share some of our experiences and learning at a few conferences including GOTO Conference 2012 (talk description & slides: A Leap from Agile to DevOps), London Devops Days 2013 (video of talk: Crossing the Uncanny Valley of Culture through Mutual Learning),  and XPDay London 2014.

During my time in London Benjamin Mitchell has been one of the biggest influences on my thinking and approach to organizational change. Benjamin has been a guide to the work of Chris Argyris and Action Science. It has been what I’ve learned from and with Benjamin that has inspired me to start the London Action Science Meetup.

Finally, I couldn’t recap the last few years without also mentioning Paul Julius and CITCON. Since I last mentioned CITCON North America in Minneapolis on this blog in 2009 we’ve gone on to organize 16 additional CITCON events worldwide, most recently in Auckland (CITCON ANZ), Zagreb (CITCON Europe), Austin (CITCON North America), and Hong Kong (CITCON Asia). For PJ and I this is our 10th year of CITCON (and OIF, the Open Information Foundation) and it has been fantastic to continue to meet people throughout the world who care about improving the way we do software development.

Categories: Blogs

Fueling Delivery Teams

Leading Agile - Mike Cottmeyer - Fri, 02/27/2015 - 20:52

I’ve started using an analogy to illustrate the importance of product owner teams in larger organizations.  When working with organizations to do an agile transformation, almost always, a tiered model is used for scaling across the organization. The model looks something like this:


The top tier is portfolio management which is responsible for investment decisions and what initiatives continue to move forward. The middle tier is representative of the Product Owner role in Scrum and is where we often create program teams, sometimes called product owner teams. The bottom tier is where stable cross-functional teams reside that are delivering increments of value in some cadence such as every two weeks.

Let me describe this engine analogy to see if it resonates with you. Stable Engines

I think of the delivery tier as the engine of the organization. Each delivery team is designed to operate at a sustainable pace in a very predictable manner. If we think of each team as an engine then we may find some operate at 2500 RPM, others 3500 RPM, regardless, they each operate at a RPM that is sustainable. If we can operate with little variance then we can start to become predictable and make promises on what can be delivered over time. If a team is running at 2500 RPM then I can determine how far that team will travel if that engine powers a car.

But, if we push the engine past a sustainable pace, or have them operate past the redline, then the engine becomes stressed, will wear out more quickly, and likely fail to deliver as expected and certainly become unpredictable.

Fuel for the Engines

Product owner teams represent refineries responsible for providing good fuel. They must understand the business goals and problems to be solved, collaborate with delivery teams to define capabilities to build, and further decompose those into clear backlog items that provide clean burning fuel needed by the engines.

Provide bad fuel – the teams sputter and are unable to run at a consistent RPM. Bad fuel will not allow us to make promises to the market or our customers.

Drilling Locations

I haven’t completely vetted this out in my mind, but when thinking about portfolio management I believe this is where we are making investments on where to drill for crude oil. We increasingly learn more about the potential initiatives, collaborate with the product owner teams, and possibly delivery teams to progressively gain more knowledge so we can make funding or cut decisions about where we will invest.

Wrapping Up

This analogy seems to resonate when I’ve used it over the last few months to describe the responsibilities of delivery teams and product owner teams. Turning crude into clean burning fuel is a big job and really highlights the challenge most organizations have in providing clarity to their delivery teams.

I would love to get your thoughts on how I’m thinking about this.

The post Fueling Delivery Teams appeared first on LeadingAgile.

Categories: Blogs

What’s the Best Conference Talk You’ve Heard?

Rally Agile Blog - Fri, 02/27/2015 - 15:00

The tech industry has long used conferences to share ideas, products, practices, and news. In this era of TED talks, YouTube, SlideShare, and livestreaming, it's easier than ever to be in the audience when thought leaders take the stage.

The best conference talks -- even if they’re virtual -- elicit a reaction that’s visceral: they make you think and act differently. Whether it’s a jarring statistic, or a humorous anecdote, or a charismatic speaking style, something about the best talks stays with you long after the talk has ended.

Ring a bell? That’s the kind of talk we’re after for RallyON 2015. Here are some talks from last year’s RallyON that people still talk about today.

What’s the most intractable, inefficient, and slow-moving organization you can think of? If you said the US government, you’re probably not alone. As we learned in this talk by former Assistant Secretary and CIO of the Department of Veterans Affairs, Roger W. Baker, implementing Agile at the VA had powerful and mind-changing consequences.

  • The department’s success rate for IT programs went from 30% to 83%.
  • The VA returned $373 million to the US Treasury budget.
  • It deployed the Veterans Benefits Management System—a $700 million program that completely replaced a paper-based system—six months ahead of schedule.

It’s rare to get a peek at how large, publicly traded enterprises do things under the hood; it’s even rarer to hear them talk about both what’s working and what’s not. So when Wendi Nagy, Program Director at Comcast, assembled a team (PMO Director Paul McGregor and Agile Coach Janelle Brunke) to share the lessons learned in the company’s Agile transformation, people listened.

  • What they did right: standardizing iteration length and using common user story formats in a single Rally workspace.
  • What they did wrong: a “never say no” culture that resulted in too much WiP.
  • What’s working: instead of delivering in silos, teams demo features to internal and external clients at the end of iterations -- earning them a great reputation for delivering.

You’ve probably heard or seen a conference talk that made you think twice, made you want to share it with everyone you know, or made you change how you do things. What’s the best one in your book? What would you like to hear at RallyON 2015? Submit to our Call for Content and tell us more in the comments below.

Rally Software
Categories: Companies

Gastblog: Ervaringen met Agile en Scrum Certificeringen

Ben Linders - Fri, 02/27/2015 - 11:02
In deze gastblog deelt Erik Philippus van ImprovemenT zijn ervaringen met diverse agile en Scrum certificeringen. Continue reading →
Categories: Blogs

What Is An Agile Team and How Do You Form Them?

Leading Agile - Mike Cottmeyer - Fri, 02/27/2015 - 11:00

An agile team is not just any random group of people. An agile team is not a group of business analysts doing a daily standup to coordinate their work. It’s not a group of developers that meet every other week to do sprint planning. It’s not a project team with folks matrixed across two or more other agile teams.

An agile team is a cross-functional group of people that have everything, and everyone, necessary to produce a working, tested increment of product. These people are dedicated to the team, and as a rule, do not move between or across teams as demand ebbs and flows.

I’m going to suggest that the very definition of an agile team… a cross-functional group of people that have everything, and everyone, necessary to produce a working, tested increment of product… is getting in the way of forming agile teams, mostly because we misunderstand what a product actually is.

In the small, this guidance is clear… it’s the system all the way from user interaction to data and back and all the abilities to deploy and install said product into production. In the large, forming a team like this isn’t usually possible, and often if possible, not advisable.

In the large, a product is actually a sub-system of a larger systems integration.

When you look at a product this way, it is often very possible to create a small cross-functional group of people that has everything, and everyone, necessary to produce a working, tested increment of product.

The idea is that you organize around products or features where you can, and you organize around subsystems where you have shared functionality. We call these collectively business capabilities. Once you have the business capabilities understood, you align the business capabilities with the technical architecture and ultimately the organizational architecture.

The intersection and alignment of business architecture, technical architecture, and organizational architecture is where you form a complete cross-functional group of people that have everything, and everyone, necessary to produce a working, tested increment of their part of the product.

Because your business architecture, technical architecture, and organizational architecture are probably broken, you are going to have dependencies between these teams that are going to have to be managed. For now.

Over time, the job of the transformation initiative is to break these dependencies.

Dependencies are evil and they need to be broken.

The more you manage dependencies the less agile you will be, period.

Over time, as you break these dependencies, you will be able to treat each of these teams as pure play agile teams.

Until you start forming teams that align business capabilities with technical architecture and organizational architecture, and begin the hard work of breaking dependencies… all you can do is go through the motions of Scrum. You will never get the value you are working towards.

I’m telling you guys… the reason you’re doing agile and not feeling very agile is because you don’t have these kinds of teams and you have way too many dependencies.

No amount of daily standup meetings is going to fix this problem.

An agile culture won’t do the hard work for you.

The post What Is An Agile Team and How Do You Form Them? appeared first on LeadingAgile.

Categories: Blogs

Ten Outsourcing Considerations

Bobtuse Bobservations - Bob MacNeal - Fri, 02/27/2015 - 04:07
Software developer testing with JUnitTen outsourcing considerations when choosing a software development team: Are they local?Are they recommended by someone you trust?Are they demonstrably...

Bobtuse can be wildly informative
Categories: Blogs

R/ggplot: Controlling X axis order

Mark Needham - Fri, 02/27/2015 - 02:49

As part of a talk I gave at the Neo4j London meetup earlier this week I wanted to show how you could build a simple chart showing the number of friends that different actors had using the ggplot library.

I started out with the following code:

df = read.csv("/tmp/friends.csv")
top = df %>% head(20)
ggplot(aes(x =, y = colleagues), data = top) + 
  geom_bar(fill = "dark blue", stat = "identity")

The friends CSV file is available as a gist if you want to reproduce the chart. This is how the chart renders:

2015 02 27 00 41 08

It’s in a fairly arbitrary order when it would be quite cool if we could get the most popular people to show from left to right.

I had the people’s names in the correct order in the data frame but annoyingly it was then sorting them into alphabetical order. Luckily I came across the by using the scale_x_discrete function which does exactly what I needed.

If we pass in the list of names to that function we get the chart we desire:

ggplot(aes(x =, y = colleagues), data = top) + 
  geom_bar(fill = "dark blue", stat = "identity") + 
  scale_x_discrete(limits= top$

2015 02 27 00 45 01

Categories: Blogs

Updated: Full-Day Product Owner Simulation

Learn more about our Scrum and Agile training sessions on

The Product Owner Simulation that I shared last summer has some minor updates based on a stronger emphasis on product vision.  In particular, two 5 minute exercises before and after the Product Box exercise help to frame the concept of product vision and make it stronger.

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!
Categories: Blogs

The One Immutable Law of Adopting Agile

Leading Agile - Mike Cottmeyer - Thu, 02/26/2015 - 10:00

I have three non-negotiables when it comes to running an agile transformation. If we are unwilling to create clear, well-articulated backlogs… if we are unwilling to form complete cross-functional teams… and if we are unwilling to produce working, tested software on regular intervals… we probably shouldn’t even get started. Without these three pre-conditions it is unlikely that adopting agile practices (or even an agile culture) will make much of a dent in terms of how you put product into market.

That said, the number one thing that gets in the way of creating clear, well-artciulated backlogs, forming complete cross-functional teams, and producing working tested software on regular intervals is dependencies. Let’s just say it… dependencies are evil. Dependencies break agile. You have two choices when faced with a dependency… you can either break it or you can manage it. The more dependencies you choose to manage instead of breaking, the less agile you will be over time.

This might just be the one immutable law of adopting agile.

The post The One Immutable Law of Adopting Agile appeared first on LeadingAgile.

Categories: Blogs

ScrumDay France, Paris, April 2-3 2015

Scrum Expert - Thu, 02/26/2015 - 09:31
ScrumDay France is a two-day conference taking place in Paris. It is focused on all aspects of Scrum with session in French but with keynotes in English. In the agenda of the ScrumDay France you can find topics like “Simple but not simplistic” avec Dave Snowden, “The Scaling Dilemma” by Mary Poppendieck, “Équipes agiles : survivre à la disparition des managers”, “Dérapage contrôlé en toute agilité!”, “Les équipes Produit à l’assaut des silos!”, “Migrez vers le Management 3.0″, “Scrum Shu Ha Ri”, . Web site: Location for the ScrumDay France conference: Disneyland ...
Categories: Communities

Lean Change Method: Enabling Lean and Agile Transformations at Scale

Jeff Anderson, Lean-Agile Advisory Practice Lead at Deloitte Canada, explains how the Lean Change method helps organizations manage agile transformations at scale through co-creation and validated learning. About This Webinar Watch this webinar recording to learn how to: – Collaboratively design a potential Agile change using a Change Canvas – Build a feedback-rich change plan through […]

The post Lean Change Method: Enabling Lean and Agile Transformations at Scale appeared first on Blog | LeanKit.

Categories: Companies

Why LeadingAgile?

Leading Agile - Mike Cottmeyer - Thu, 02/26/2015 - 03:47

We are working on more video for the site to tell our story. This is the first stab.

The post Why LeadingAgile? appeared first on LeadingAgile.

Categories: Blogs

R: Conditionally updating rows of a data frame

Mark Needham - Thu, 02/26/2015 - 02:45

In a blog post I wrote a couple of days ago about cohort analysis I had to assign a monthNumber to each row in a data frame and started out with the following code:

monthNumber = function(cohort, date) {
  cohortAsDate = as.yearmon(cohort)
  dateAsDate = as.yearmon(date)
  if(cohortAsDate > dateAsDate) {
  } else {
    paste(round((dateAsDate - cohortAsDate) * 12), sep="")
cohortAttendance %>% 
  group_by(row_number()) %>% 
  mutate(monthNumber = monthNumber(cohort, date)) %>%
  filter(monthNumber != "NA") %>%
  filter(monthNumber != "0") %>% 
  mutate(monthNumber = as.numeric(monthNumber)) %>% 

If we time this function using system.time we’ll see that it’s not very snappy:

system.time(cohortAttendance %>% 
  group_by(row_number()) %>% 
  mutate(monthNumber = monthNumber(cohort, date)) %>%
  filter(monthNumber != "NA") %>%
  filter(monthNumber != "0") %>% 
  mutate(monthNumber = as.numeric(monthNumber)) %>% 
   user  system elapsed 
  1.968   0.019   2.016

The reason for the poor performance is that we process each row of the data table individually due to the call to group_by on the second line. One way we can refactor the code is to use the ifelse which can process multiple rows at a time:

cohortAttendance %>% 
  mutate(monthNumber = ifelse(as.yearmon(cohort) > as.yearmon(date), 
                              paste((round(as.yearmon(date) - as.yearmon(cohort))*12), sep=""), 
   user  system elapsed 
  0.026   0.000   0.026

Antonios suggested another approach which involves first setting every row to ‘NA’ and then selectively updating the appropriate rows. I ended up with the following code:

cohortAttendance$monthNumber = NA
cohortAttendance$monthNumber[as.yearmon(cohortAttendance$cohort) > as.yearmon(cohortAttendance$date)] = paste((round(as.yearmon(cohortAttendance$date) - as.yearmon(cohortAttendance$cohort))*12), sep="")

Let’s measure that:

system.time(paste((round(as.yearmon(cohortAttendance$date) - as.yearmon(cohortAttendance$cohort))*12), sep=""))
   user  system elapsed 
  0.013   0.000   0.013

Both approaches are much quicker than my original version although this one seems to be marginally quicker than the ifelse approach.

Note to future Mark: try to avoid grouping by row number – there’s usually a better and faster solution!

Categories: Blogs

Cultural Judo – How to Change Culture Without Changing Culture

Leading Agile - Mike Cottmeyer - Thu, 02/26/2015 - 01:21

There are a bunch of us out there that are super passionate about this notion of agile as a cultural framework… or a value system… or a mindset. If you’ve been following this blog for any length of time, I suspect you’ll know where I stand on this. I think that culture, values, and mindset are important… but they aren’t why we adopt agile. We adopt agile to build better software, software that our customers want to use, and to get better economic outcomes for our companies.

To the extent that culture, values, and mindset lead to those outcomes… great… but culture, values, and mindset are not why we adopt agile. They are a byproduct.

If we allow for a moment that culture, values, and mindset are a necessary precondition for adopting agile… let’s think through what that actually means. Let’s say we have a traditional organization… functionally soloed… tightly coupled legacy architecture… matrixed, project based delivery system… overlapping, intertwined value streams… power struggles between executives… compensation models that reinforce and incentivize around the existing system… and all the cultural toxicity that you might expect comes along with this… what do you do?

Do you come in and give everyone a pep talk on the value of agile? Do you invite them to participate and hope that they all agree and self-organize into a new, rational delivery model? Do you run them through ScrumMaster training and have them bring back a bunch of practices that are incongruent with their existing culture and delivery framework? How do you create safety for people to step out and try new things? What if the team level folks all see the value, but those in power with the most to loose don’t?

I’d suggest that you can’t attack culture by attacking culture. You have to meet the organization where it is today and use it’s own weight against it.

Most people in these kinds of organizations recognize that something is broken and that something needs to be fixed… they just don’t trust everyone around them to necessarily work in their best interest to fix it. Our approach is to use the organizations need for predictability and control to actually create the conditions where agile practices and culture can take hold. We know that agile creates more visibility, more insight into what’s going on, better ability to make and meet commitments than any sequential process.

We have to use agile to get the organization what it needs and to create the conditions for change. We create the conditions for agile by creating the org patterns that enable agility.

When you are promising the organization what it wants now… predictability, quality, early return on investment… and can make the case that all this agile stuff gets them there faster… you can begin the change without even mentioning culture, values, or mindset. Instead, you talk about backlogs, teams, and working tested software delivered on regular intervals. You talk about metrics and planning. You talk about the ability to realize revenue earlier, you talk about creating clean breakpoints where we can change direction, you talk about having greater ability to make and meet commitments.

None of this is incongruent with where we want to go… none of this is incongruent with evolving a healthier culture, living agile values, or adopting an agile mindset… those things just aren’t where we start. We start by adopting an agile system of delivery, a system that delivers the business results your company so desperately needs, while creating the conditions for more agile practices to take root… and a more agile culture to emerge over time. You are never going to change culture by telling everyone they are doing it wrong and need to change.

My belief is that to effectively change culture, you have to create safety… you have to create alignment… you have to create congruence between your desired outcomes and rewards. You have to have a rational system of delivery that allows people to show up for work, to be able to do what they are being asked to do, and really see and feel what it is like to be successful in that new model. In an organization with a highly toxic culture, you have to lead with a point of view and a plan and push the organization to change… I don’t believe pull will work.

I think culture, values, and mindset are important, but I tend to see them as a byproduct of a rational system of delivery… a system of delivery that creates safety for everyone involved… a system of delivery that allows those cultural norms, applied values, and mindset to emerge over time. People ask me all the time how to sell agile to your executives… the answer is to simply stop talking about what we want to accomplish with agile and start aligning agile to the business drivers that are most important to your executives.

Use the organizations weight against it. Sell the organization a way to solve it’s business problems… you’ll get the culture change for free.

The post Cultural Judo – How to Change Culture Without Changing Culture appeared first on LeadingAgile.

Categories: Blogs

SAFe News: LSE Big Picture updates, Preview Schedule and More

Agile Product Owner - Wed, 02/25/2015 - 21:57

Hi Folks,

Many of us have been heads-down with LSE development (and admittedly a bit behind our planned power curve), so we haven’t communicated as frequently as we would like. But here’s a quick update:

  • We’ve received a lot of feedback about the evolution of the SAFe LSE Big Picture, the framework structure and intent, and its potential impact on SAFe 4.0. Long story short: PIs will be PIs in both LSE and SAFe 4.0 (Quantum is dead). Lots of other changes as well, as you can see from the latest revision of the BP, below.
  • The “Preview” version of the LSE framework will go live (publicly facing) in the next week or so. Most articles are in place, though some will only have abstracts initially. All articles, including the abstract-only ones, will be open for public comments through the WordPress comment mechanism. The framework will continue to evolve over the course of this year, with feedback open to the public for the next six months or so. Our plan is to reach V1.0 (all articles complete and revised a few times, certainly some new articles, Guidance, Glossary etc.) later in the year.
  • The first LSE training, “Applied Lean Systems Engineering with SAFe LSE “, a three day course, will be held April 14-16 in Boulder, CO. Space is still available. Register here. Additional sessions are scheduled later in the year, check Scaled Agile Academy for details.  Those later courses will be four day courses, with the fourth day intended for the SAFe Systems Consultant (SSC) certification process. However, that process will begin at the March class, and attendees that wish for certification will be automatically enrolled in SSC Certification process. We’ll provide some ongoing training, an exam, etc. (Attendees will not have to attend an additional class to become certified.)

And here is the new BP!

SAFe LSE Big Picture (rev 59)

SAFe LSE Big Picture (rev 59)

In other SAFe news:
  • SAFe 4.0 continues in development with an August 2015 release.  Richard Knaster is leading that charge. We’ll sneak preview that BP update shortly.
  • A new video book, Leading SAFe Live Lessons, an in-depth exploration of the principles and practices of the Scaled Agile Framework,  will be published by Pearson in about a month. Based on Leading SAFe, this 7-hr hour video text is my first foray into video books. I think it worked out ok. It will be included in Pearson’s Safari Books On Line series for those who subscribe, put will also be purchasable independently as well.
  • Leading SAFe 9, with a new pedagogy (following the Live Lesson’s Lesson and sub-lesson format), will also be release this summer. A couple of other new courses will also be released this summer.
  • Richard Knaster is working hard on a new book: SAFe Distilled, a 180 page overview of the framework. It’s about half written and will be released sometime towards the end of summer. It will be based on SAFe4.0

That’s it for the moment.

Stay tuned and stay SAFe!



Categories: Blogs

“At Scale” Is For Fortune Cookies

Rally Agile Blog - Wed, 02/25/2015 - 17:52

Have you heard about the fortune cookie meme where you read your fortune cookie and then add the phrase “in bed” to the end of it? For example:

You will learn a lot today … in bed.

A dream you have will come true … in bed.

Funny ... and maybe a little immature.

Well in the business world, the same thing works for the phrase “at scale.”

Maintain quality … at scale.

Coordinate work across development teams … at scale.

All things are difficult before they are easy … at scale.

The fact is, “at scale” can mean 100 different things based on your context. Are we talking about scaling one database up to thousands of databases? Are we talking about a system working with 10 users, as opposed to 10 million? Is it one team vs. 100 teams? A recent Huffington Post article described 10 things you can do to appear smarter during meetings; tip #6 is, “Ask ‘Will this scale?’ no matter what it is.”  

“At scale” can mean so many different things that it can become meaningless.

Here at Rally, “at scale” means distributing Agile techniques across locations, across departments, and across business units. It means solving the problem of coordinating the work of hundreds of teams to get the top business initiatives completed, driving value across the enterprise. Companies do this in many different ways. Some practice SAFe®, some use LESS, and others have created a blend of both or invented their own. No matter what framework these companies are using, the problem they're solving is the same. How do you deliver high-quality value to your customers in an efficient and predictable manner?

Here, we try to drink our own champagne. We continuously seek to find ways to improve, and at times we will bring in our own transformation consulting to evaluate how to take the next step in our Agile journey. We’ve done this just in the last year, and as a result we’ve solved some internal problems and substantially increased our feature velocity.  

At Rally, we challenge ourselves not to hide behind the vague problem of “at scale.” We think about how we can help you deliver business value faster, whether you've got a single team or hundreds of teams, and we think about the problems we can help you solve. Are you struggling to get your first Agile team up and running? Are you trying to convince executives that an Agile transformation is the only way you can stay ahead of the market? Are you looking for a way to plan and collaborate remotely across your seven development locations? Rally can help by connecting you to world-class coaches, products, partners, and other customers.

Talk to us about the problems you face in getting business done ... at scale. We probably have a solution for you.  

  Stephanie Tanner
Categories: Companies

Eating the dog food

Sonar - Wed, 02/25/2015 - 17:36

The SonarQube platform includes an increasing powerful lineup of tools to manage technical debt. So why don’t you ever see SonarSourcers using Nemo, the official public instance, to manage the debt in the SonarQube code? Because there’s another, bleeding-edge instance where we don’t just manage our own technical debt, we also test our code changes, as soon as possible after they’re made.

Dory (do geeks love a naming convention, or what?), is where we check our code each morning, and mid-morning, and so on, and deal with new issues. In doing so, each one of us gives the UI – and any recent changes to it – a thorough workout. That’s because Dory doesn’t run the newest released version, but the newest milestone build. That means that each algorithm change and UI tweak is closely scrutinized before it gets to you.

The result is that we often iterate many times on any change to get it right. For instance, SonarQube 5.0 introduced a new Issues page with a powerful search mechanism and keyboard shortcuts for issue management. Please don’t think that it sprang fully formed from the head of our UI designer, Stas Vilchik. It’s the result of several months of design, iteration, and Continuous Delivery. First came the bare list of issues, then keyboard shortcuts and inter-issue navigation, then the wrangling over the details. Because we were each using the page on a daily basis, every new change got plenty of attention and lots of feedback. Once we all agreed that the page was both fully functional and highly usable, we moved on.

The same thing happens with new rules. Recently we implemented a new rule in the Java plugin based on FindBugs, "Serializable" classes should have a version id. The changes were made, tested, and approved. Overnight the latest snapshot of the plugin was deployed to Dory, and the next morning the issues page was lit up like a Christmas tree.

We had expected a few new issues, but nothing like the 300+ we got, and we (the Java plugin team and I) weren’t the only ones to notice. We got “feedback” from several folks on the team. So then the investigation began: which issues shouldn’t be there? Well, technically they all belonged: every class that was flagged either implemented Serializable or had a (grand)parent that did. (Subclasses of Serializable classes are Serializable too, so for instance every Exception is Serializable.) Okay, so why didn’t the FindBugs equivalent flag all those classes? Ah, because it has some exclusions.

Next came the debate: should we have exclusions too, and if so which ones? In the end, we slightly expanded the FindBugs exclusion list and re-ran the analyses. A few issues remained, and they were all legit. Perfect. Time to move on.

When I first came to SonarSource and I was told that the internal SonarQube instance was named Dory, I thought I got it: Nemo and Dory. Haha. Cute. But the more I work on Dory, the more the reality sinks it. We rely on Dory on a daily basis; she’s our guide on the journey. But since our path isn’t necessarily a straight line, it’s a blessing for all of us that she can forget the bad decisions and only retain the good.

Categories: Open Source

Cool: Scrum Your Wedding

Learn more about our Scrum and Agile training sessions on

Scrum has really come far!!!  Check out “Scrum Your Wedding“.  I love the ScrumMaster and Product Owner tips.  Here’s a good one:

SCRUM MASTER TIP – The stand-up is overkill in most wedding planning scenarios, but we do think it’s useful to ask the questions at least a few times per sprint, perhaps over email. It’s your job to make sure the questions are asked and answered.

They have taken the core ideas of Scrum and made some intelligent modifications to make it suitable for a fixed deadline event planning scenario.  Honestly, I think that the ideas presented here could be a great approach to doing Scrum on other similar fixed deadline projects.  Thanks to Hannah Kane and Julia Smith for creating a unique and useful resource!

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!
Categories: Blogs

Das geheime Leben der Checklisten

Scrum 4 You - Wed, 02/25/2015 - 08:39

Braucht man eine Checkliste für Scrum? Ist Scrum nicht so simpel, dass man sich die paar Meetings, Artefakte und Rollen nicht einfach merken kann?

Auf den ersten Blick braucht man bestimmt keine Checkliste für diesen Prozess. Doch wie ist das in großen Projekten, wenn man Scrum skalieren will? Wäre es dann nicht gut, wenn alle Scrum immer auf die gleiche Art erledigen würden und damit ein Standard entstehen würde? Bei meinen ersten Ideen zu Checklisten war genau das die Motivation. Wir wollten erreichen, dass wirklich alle wissen, wie man Scrum erfolgreich einsetzen kann. Im Laufe der Jahre haben sich aber auch immer wieder Kollegen gemeldet, die sagten:

  • „Das schränkt meine Freiheit ein!”
  • „Da fehlt ein wichtiger Schritt.“
  • „Das Team soll doch entscheiden, wie Scrum gelebt wird, nicht eine doofe Checkliste.”

Natürlich haben diese Widerstände ihren Sinn und sie weisen darauf hin, dass Checklisten nicht perfekt sind. Doch sie erfüllten ihren Zweck und deshalb gibt es sie heute noch so wie vor ein paar Jahren. Aber was macht man mit den Leuten, die einerseits recht haben, doch andererseits etwas übersehen? Die Welt wird immer komplexer, die Projekte immer größer und die Anforderungen an die ScrumMaster und Teammitglieder immer ausgefeilter. Heute reicht es nicht mehr, ein Scrum-Team zu koordinieren. Heute sollen viele Teams an unterschiedlichen Standorten mit unterschiedlichen Spezialisierungen zusammenarbeiten – und sich standortübergreifend verständigen und verstehen. Könnten dabei nicht vielleicht doch wieder Checklisten helfen? Wer nutzt denn eigentlich Checklisten?

Checkliste checked, Patient lebt

Bei diesem Gedanken bin ich zufällig auf das sehr lesenswerte Buch  “The Checklist Manifesto” von Atul Gawande gestoßen und habe mir anschließend eine Checkliste der WHO angesehen: die „Surgical Safety Checklist“. (Die Ärztekammer Wien hat eine wunderbare Interpretation dieser Checkliste und ihrer Geschichte verfasst, sie hier)

Atul Gawande stand im Operationssaal und hatte exakt die gleichen Probleme wie wir bei unseren Scrum-Teams. Die Mitglieder des Operationsteams wechselten von Operation zu Operation und hatten oft noch nie gemeinsam gearbeitet. Jedes Teammitglied war ein absoluter Spezialist, Gawande nennt das Hyperspezialisierung: Ärzte leben eine Kultur, in der jeder Arzt für sich den Meister-Status hat. Er macht keine Fehler und weiß alles. Doch Gawande war aufgefallen, dass in unserem neuen medizinischen Zeitalter die Spezialisierungen und die Anzahl der Operationen mit ihren Millionen von Varianten so umfangreich geworden sind, dass ein Mensch gar nicht mehr alles wissen, geschweige denn alles richtig machen kann. Gawandes einfache Idee war es, mit Hilfe von Checklisten – wie auch Piloten sie verwenden – die Zahl der Todesfälle in Krankenhäusern zu reduzieren. Der Durchbruch gelang ihm viele Jahre später mit der oben genannten Surgical Safety Checklist. “Nach Implementierung der Checkliste fiel die Rate schwerer Komplikationen von 11% auf 7%, die Mortalitätsrate großer Operationen von 1,5% auf 0,8%.“ (Ärztekammer Wien)

Teamspirit durch Abhaken

Das Erstaunlichste jedoch ist, dass diese Checkliste nicht als mechanisches Instrument zu verstehen ist, das nur heruntergelesen wird und alle nicken dazu. In Wahrheit dient sie dazu, im Operationssaal ein Teamgefühl zu etablieren – aus Fremden macht sie in Minuten ein engagiertes Team. In seinem Buch beschreibt Gewande diesen Umstand sehr deutlich: Es gehe nicht um das gedankenlose Ausführen von To Do’s auf der Checkliste. Die eigentliche Stärke der Checkliste liege darin, dass durch das Fragen ein soziales System entsteht, in dem sich jeder einbringen kann und sofort seine Rolle versteht.

Laut Gawande haben Checklisten zwei Funktionen:

  1. Die Checklisten verhindern, dass wichtige wiederkehrende Dinge vergessen werden.
  2. Sie dienen dazu, das Chaos zu reduzieren, indem sie das Team zum Innehalten zwingen, um darüber nachzudenken, ob es Besonderheiten gibt.

Letzteres ist der eigentlich wichtige Fall: Die Routineaufgaben sind den meisten bekannt und hier werden nur Flüchtigkeitsfehler gemacht. Doch was, wenn etwas nicht so ist, wie es sein sollte? Läuft etwas im OP nicht wie geplant, macht die Checkliste darauf aufmerksam, dass man nun in den „Emergency Modus“ gehen und miteinander reden muss. Auf diese Weise entstehen Checklisten 2. Ordnung. Die Checkliste wird zu einem Rahmenwerk und nicht mehr zu einer To-Do-Liste.

Legt man diesen Gedanken auf unsere Scrum-Checklisten für die Arbeit mit großen Teams um, bedeutet das für mich: Vielleicht können wir den Scrum-Teams in Zukunft noch besser helfen, wenn die Checklisten als Checklisten 2. Ordnung verstanden werden und wir sie vielleicht sogar mit den Teams erstellen. So können sich Teams noch besser koordinieren und die wichtigsten Probleme schneller erkennen. Gerade in großen Projekten wird das sicher zunehmend wichtiger werden.

Vielleicht habt ihr ja eine Idee für eine solche Checkliste und wollt sie mit uns teilen?

Categories: Blogs

Knowledge Sharing

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