Skip to content

Feed aggregator

Protecting Agile Projects from Consultants

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

Measurements Towards Continuous Delivery

Learn more about our Scrum and Agile training sessions on

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

Lead time per work item to production

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

Cycle time to “done”

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

Escaped defects

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

Defect fix times

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

Total regression test time

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

Time the build can be broken

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

Continuous delivery isn’t possible with a broken build.

Number of branches in version control

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

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

Production outages during deployment

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

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

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

11 Tips for a Successful Scrum Implementation

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

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

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

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

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

Actually, YESTERDAY.

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

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

Are you STUCK?

Here’s the secret:

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


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

Let me help you. Let’s talk.


Here are TEN FREE STEPS to start on your own:


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


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

Here is what you can do.


Identify your most important (valuable?) client today.

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

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

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

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

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

It’s OK.

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

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


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

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



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

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


Watch the magic happen.


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

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


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


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

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


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

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


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


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

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

Focus. #deliver


Gather your team for a Sprint Retrospective.

Learn together about what can improved in the next Sprint.


Keep going.

That’s it.

Focus. #deliver

Need help?




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

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

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

Focus.  #deliver


Keep learning.

This is all good.



I can help.


Categories: Blogs

The Myths of Business Model Innovation

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

Business model innovation has a couple of myths.

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

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

The "Think Big" Myth

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

Via The Business Model Navigator:

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

The Technology Myth

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

Via The Business Model Navigator:

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

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

You Might Also Like

Cloud Changes the Game from Deployment to Adoption

Cognizant on the Next Generation Enterprise

Drive Digital Transformation by Re-Imagining Operations

Drive Digital Transformation by Re-envisioning Your Customer Experience

The Future of Jobs

Categories: Blogs

Scrum Alliance Launches Learning Consortium

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

Crossing the Agile-UX Divide

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

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

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

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

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

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

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

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

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

Catherine Connor
Categories: Companies

Thinking About Estimation

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

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

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

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

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

Categories: Blogs

February Dallas Recap: Discover the Power of Pair Testing

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

The Next Most Important Thing

Leading Agile - Mike Cottmeyer - Tue, 04/21/2015 - 14:16

Finding your next most important thing is critical and requires clarity. As teams begin thinking about how to address their meetings, the topic of a previous post, its critical that they first identify where the team needs to focus its energy over the next 1-3 months, or the “next most important thing” the team needs to do in order to succeed.

So, how would a team go about identifying their “next most important thing”… It’s a fairly straightforward process.

For the sake of a tangible example, I’d like to use a set of three types of teams that I work with on a regular basis, teams that operate within a three tier enterprise product development structure. These teams and their purpose would be defined as follows:

  • Product development team: Produce the next most important working increment of product within a couple of weeks.
  • Program team: Establish and provide clarity for and to product development teams about the next most important increments of product that are needed within the next few months.
  • Enterprise portfolio team: Establish and provide clarity for and to program teams about their next most important thing for the portfolio to succeed. This usually requires creating or maintaining a multi-quarter capacity-aligned roadmap for the products and services that are owned by the portfolio.

With these perspectives in mind here is the process that I would recommend for identifying the next most important thing within each team:

  1. Review the team’s primary purpose,
  2. Ask each team member to write down the one thing within its control that is keeping the team from fulfilling its primary purpose,
  3. Review the team’s suggestions and filter the list down to the one thing that the team agrees is the most important goal for the next period.

It’s important to recall that the next most important thing for a portfolio team may look very different from the next most important thing for a product development team.

So, how would a portfolio team member identify the portfolio’s next most important thing? I’d recommend that they answer this question:

What is keeping our portfolio from delivering the next most important increments of product into the markets within the next 3-9 months?

Likewise for a program team member I would recommend the following question:

What is keeping our program from providing clarity to the product development teams about the next most important increment of product?

And finally for a product development team I would recommend the following question be answered:

What is keeping our team from delivering a working increment of product within a couple of weeks?

In each of these cases, the next most important thing would be directly tied back to the primary purpose for the team and would be expected to be resolved within a short period. Once we know what the next most important thing for the team is, we can start to identify which types of meetings we will need and how frequently we will need them to ensure that we are accomplishing our next most important thing.

What do you think, are there other examples that you would like to hear more about or perhaps where you have seen this fail?

And as always, thanks for reading and sharing your feedback!

The post The Next Most Important Thing appeared first on LeadingAgile.

Categories: Blogs

Agile Day Riga, Riga, Latvia, May 23 2015

Scrum Expert - Tue, 04/21/2015 - 09:49
Agile Day Riga is a one-day conference focused on Agile project management and Scrum. Presentations and workshops will be in Latvian, English and Russian. In the agenda of Agile Day Riga you can find topics like “Being Agile to become Customer centric”, “Agile Innovation – Why people matters”, “Agile Metrics – what is really needed and makes sense in order to steer a large agile project “, “Is “your” Scrum working?” , “Software architecture also needs Agile”, “Why We Fail to Change”. Web site: Location for the Agile Day Riga conference: Islande ...
Categories: Communities

Swift optional chaining and method argument evaluation

Xebia Blog - Tue, 04/21/2015 - 09:21

Everyone that has been programming in Swift knows that you can call a method on an optional object using a question mark (?). This is called optional chaining. But what if that method takes any arguments whose value you need to get from the same optional? Can you safely force unwrap those values?

A common use case of this is a UIViewController that runs some code within a closure after some delay or after a network call. We want to keep a weak reference to self within that closure because we want to be sure that we don't create reference cycles in case the closure would be retained. Besides, we (usually) don't need to run that piece of code within the closure in case the view controller got dismissed before that closure got executed.

Here is a simplified example:

class ViewController: UIViewController {

    let finishedMessage = "Network call has finished"
    let messageLabel = UILabel()

    override func viewDidLoad() {

        someNetworkCall { [weak self] in

    func finished(message: String) {
        messageLabel.text = message

Here we call the someNetworkCall function that takes a () -> () closure as argument. Once the network call is finished it will call that closure. Inside the closure, we would like to change the text of our label to a finished message. Unfortunately, the code above will not compile. That's because the finished method takes a non-optional String as parameter and not an optional, which is returned by self?.finishedMessage.

I used to fix such problem by wrapping the code in a if let statement:

if let this = self {

This works quite well, especially when there are multiple lines of code that you want to skip if self became nil (e.g. the view controller got dismissed and deallocated). But I always wondered if it was safe to force unwrap the method arguments even when self would be nil:


The question here is: does Swift evaluate method argument even if it does not call the method?

I went through the Swift Programming Guide to find any information on this but couldn't find an answer. Luckily it's not hard to find out.

Let's add a method that will return the finishedMessage and print a message and then call the finished method on an object that we know for sure is nil.

override func viewDidLoad() {

    let vc: ViewController? = nil

func printAndGetFinishedMessage() -> String {
    println("Getting message")
    return finishedMessage

When we run this, we see that nothing gets printed to the console. So now we know that Swift will not evaluate the method arguments when the method is not invoked. Therefore we can change our original code to the following:

someNetworkCall { [weak self] in
Categories: Companies

R: Numeric keys in the nested list/dictionary

Mark Needham - Tue, 04/21/2015 - 07:59

Last week I described how I’ve been creating fake dictionaries in R using lists and I found myself using the same structure while solving the dice problem in Think Bayes.

The dice problem is described as follows:

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

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

Here’s a simple example of the nested list that I started with:

dice = c(4,6,8,12,20)
priors = rep(1.0 / length(dice), length(dice))
names(priors) = dice
> priors
  4   6   8  12  20 
0.2 0.2 0.2 0.2 0.2

I wanted to retrieve the prior for the 8 dice which I tried to do like this:

> priors[8]

That comes back with ‘NA’ because we’re actually looking for the numeric index 8 rather than the item in that column.

As far as I understand if we want to look up values by name we have to use a string so I tweaked the code to store names as strings:

dice = c(4,6,8,12,20)
priors = rep(1.0 / length(dice), length(dice))
names(priors) = sapply(dice, paste)
> priors["8"]

That works much better but with some experimentation I realised I didn’t even need to run ‘dice’ through the sapply function, it already works the way it was:

dice = c(4,6,8,12,20)
priors = rep(1.0 / length(dice), length(dice))
names(priors) = dice
> priors["8"]

Now that we’ve got that working we can write a likelihood function which takes in observed dice rolls and tells us how likely it was that we rolled each type of dice. We start simple by copying the above code into a function:

likelihoods = function(names, observations) {
  scores = rep(1.0 / length(names), length(names))  
  names(scores) = names
dice = c(4,6,8,12,20)
l1 = likelihoods(dice, c(6))
> l1
  4   6   8  12  20 
0.2 0.2 0.2 0.2 0.2

Next we’ll update the score for a particular dice to 0 if one of the observed rolls is greater than the dice’s maximum score:

likelihoods = function(names, observations) {
  scores = rep(1.0 / length(names), length(names))  
  names(scores) = names
  for(name in names) {
      for(observation in observations) {
        if(name < observation) {
          scores[paste(name)]  = 0       
dice = c(4,6,8,12,20)
l1 = likelihoods(dice, c(6))
> l1
  4   6   8  12  20 
0.0 0.2 0.2 0.2 0.2

The 4 dice has been ruled out since we’ve rolled a 6! Now let’s put in the else condition which updates our score by the probability that we got the observed roll with each of valid dice. i.e. we have a 1/20 chance of rolling any number with the 20 side dice, a 1/8 chance with the 8 sided dice etc.

likelihoods = function(names, observations) {
  scores = rep(1.0 / length(names), length(names))  
  names(scores) = names
  for(name in names) {
      for(observation in observations) {
        if(name < observation) {
          scores[paste(name)]  = 0
        } else {
          scores[paste(name)] = scores[paste(name)] *  (1.0 / name)
dice = c(4,6,8,12,20)
l1 = likelihoods(dice, c(6))
> l1
         4          6          8         12         20 
0.00000000 0.03333333 0.02500000 0.01666667 0.01000000

And finally let’s normalise those scores so they’re a bit more readable:

> l1 / sum(l1)
        4         6         8        12        20 
0.0000000 0.3921569 0.2941176 0.1960784 0.1176471
Categories: Blogs

Kommen sie oder kommen sie nicht – das ist hier die Frage

Scrum 4 You - Tue, 04/21/2015 - 07:45

Ich schaue in erstaunte Gesichter. Die Augen drücken es in Leuchtbuchstaben aus: „Wie … alle Meetings, auch die Scrum Meetings sollen freiwillig sein?“ Ich könnte schwören, dass ich die Gedanken der Manager höre, die zum Training „Selbstorganisation braucht Führung“ gekommen sind: „Aber ich muss doch meinen Mitarbeitern sagen, was ich ihnen sagen muss! Wie sieht das denn aus, wenn ich da alleine sitze und keiner kommt?“

Es dauert nicht lange und tatsächlich werden genau diese Fragen gestellt:

  • Wie kann ich denn dann gewährleisten, dass die Mitarbeiter die notwendigen Informationen bekommen?
  • Wie kann ich meinen Mitarbeitern meinen Rat geben?
  • Wie kann ich dafür sorgen, dass sie machen, was ich von ihnen will?

Die Unsicherheit ist greifbar und ich kann das gut nachvollziehen. Mir ist es auch so gegangen, nachdem ich mich dazu entschieden hatte, alle Meetings und Zusammenkünfte in unserem Unternehmen unter das Motto der freiwilligen Teilnahme zu stellen. Meine Unsicherheit war riesig, als ich das tat. Aber je mehr ich mich mit diesem Thema auseinandersetzte, desto klarer wurde mir, dass es sich auch wirklich nur um meine eigene Unsicherheit handelte. Es ist doch komisch: Warum konnte ich nicht einfach davon ausgehen, dass sich mein Team gerne treffen würde, wenn ein Teammitglied oder ich als Geschäftsführer zu einer Besprechung einlädt? Zu einer Geburtstagsfeier kommen Freunde und Familie doch auch, da stellt sich die Frage gar nicht. Sicher, es kann immer etwas dazwischenkommen, aber dann teilt die betreffende Person das respektvoll mit und ist sich im Klaren darüber, dass sie den Gastgeber verletzt, wenn sie nicht kommen kann/will.

Sie sagen jetzt möglicherweise, dass sei nicht vergleichbar. Das eine ist eine Feier und das hier ist Arbeit. Aber ist das tatsächlich so? Gehen Kollegen in ein Meeting, weil sie miteinander arbeiten wollen? Oder gehen sie hin, weil sie das Gefühl haben, dass der Chef es so will – aber eigentlich langweilen sie sich dort? Ich denke, dass angesichts der unzähligen Meetings in einem Unternehmen die Kollegen nicht immer mit vollem Interesse und Enthusiasmus dabei sind, sondern weil sie eben müssen. Es geht gar nicht um Respekt vor dem Vorgesetzten, auch nicht um Anstand – es ist einfach Gewohnheit.



Keine Angst vor dem leeren Raum

Wer Meetings das Vorzeichen der freiwilligen Teilnahme gibt, gibt sich und seinem Team auch eine Chance: Als Führungskraft erkennen Sie, ob das Meeting und damit ihr Thema bei den Mitarbeitern auf Interesse stößt. Ja, es könnte sein, dass Sie ganz alleine im Raum sitzen (obwohl es sehr unwahrscheinlich ist). Nehmen Sie das Ihren Kollegen dann bitte nicht übel, sondern nutzen Sie die Gelegenheit, um in Ruhe an Ihrem Thema zu arbeiten. Vielleicht nutzen Sie die Zeit auch, um zu einem neuen Meeting einzuladen – mit einer Formulierung, bei der die Kollegen Lust bekommen, an diesem Meeting teilzunehmen. Wir sind alle nur Menschen. Auch ich falle immer wieder in die eigene Unsicherheit und in das eigene Unverständnis zurück, wenn ich einlade und dann alleine dasitze … das passiert tatsächlich. Und leider zeigt das oft, dass ich mir nicht genügend Mühe mit der Einladung, dem Zweck der Zusammenkunft gegeben habe. Und manchmal ist es einfach so: Wer nicht kommt, hat vielleicht wirklich etwas Wichtigeres zu tun.

Wenn Sie sich mit diesem Gedanken anfreunden wollen: Mehr dazu schreibe ich in meinem Buch “Selbstorganisation braucht Führung”. Oder wir diskutieren darüber beim nächsten Training am 1. September 2015 in Wien.

Categories: Blogs

Enhanced Lean Metrics: More Speed and Insight

To find improvement opportunities, you look to the data. It offers the hard numbers that can help answer questions such as “Will we finish the work in time?” or “How can we adjust the process to improve flow?” LeanKit’s metrics and reports provide you with the data-driven insights you need to answer the tough questions. […]

The post Enhanced Lean Metrics: More Speed and Insight appeared first on Blog | LeanKit.

Categories: Companies

The Critical Aspect of DevOps You’re Overlooking

Agile Management Blog - VersionOne - Mon, 04/20/2015 - 19:04

shutterstock_95440231DevOps tends to be viewed through a technical lens, but the people aspect is what will dictate your success or failure.

So, how are the people challenges of DevOps more important than the technical challenges?

Recently I was reading Puppet Labs’ State of DevOps Report. Similar to VersionOne’s 9th annual State of Agile™ survey, this report has an interesting set of conclusions about the current state of DevOps. One of the things that I’ve been considering for some time is the strange proximity of DevOps people to technical problems.

There are a lot of technical aspects to doing DevOps. One example is continuous integration. When releasing, everything needs to be integrated and checked, no matter how small. DevOps takes it one step further with continuous deployment since you need to set up acceptance tests and unit tests, and all tests have to be automated.

One of the aspects of DevOps that reading this survey reinforced for me is that the folks who do DevOps the most successfully focus on the people aspect as much as, or sometimes even more than, the technical aspect. This brings the Gerry Weinberg conundrum to mind. Gerry Weinberg, considered by some to be the grandfather of agile, said that there’s always a people problem. The technical focus of DevOps may lead you to think that there isn’t a people aspect to focus on. In reality, while the technical piece is a focus, the people problem is huge and even more important.

DevOps is about bringing the functions of operations and development together, which means you have to break some stereotypes. You have to think outside the box. Those on the DevOps team must have the will to think about each one of the development stories through the post-deployment lens. Do you have monitoring as part of what you’re doing? Do you have performance constantly tested? Do you have all aspects of your tests automated? If not, then you’re probably not going to be as successful with DevOps.

This sounds technical, but it’s actually more of a people problem. It’s employing DevOps engineers who remember to do that. It’s not asking the question of should you automate, but how will you automate this specific story? That’s huge and it’s vital. It needs to be addressed and it needs to be addressed successfully. If you don’t, then you’re not tall enough to ride the ride. It’s not worth your time and energy to claim to be DevOps if you can’t do those things. DevOps takes time, energy and nurturing. It takes the willingness for individuals to step up. And it takes the willingness for management to step back and give your people the opportunity.

There were a couple of other fascinating people issues that that survey brought to light. The number one key to success in an IT organization, according to this survey, was employee happiness. This is an aspect people need to listen to this and build on. Employee happiness is number one. It proves that even geeky programmers like me don’t derive our employee happiness only from the really cool tools we get to use and work on. It’s nice, but it’s not enough.

The other fascinating people issue was getting the whole team together to work on the issues, thus becoming a cross-functional team. Everybody is responsible for everything, and that makes a huge difference in the DevOps world, even more so than in the traditionally agile world. Teamwork is where you’re really going to see the difference between just checking things in all the time and continuous deployment.

DevOps lends itself to being viewed through a technical lens, but the people aspect is what differentiates you from success or failure. I hope I have inspired you to take a closer look at how you are balancing the people aspect of DevOps with the technical.

So, what are some other people aspects of DevOps that should be focused on?

Need assistance with a Continuous Delivery/DevOps Assessment? Click here for info.

VersionOne and State of Agile are registered trademarks of VersionOne Inc.

Categories: Companies

Adopt a Californian: Systems, and the California Drought

Powers of Two - Rob Myers - Mon, 04/20/2015 - 17:53
I'd like to invite you to #AdoptACalifornian ("...before we're all extinct!" ;-)  It's extremely easy, and may just be good for you, too.
The System We Live InYou've likely heard that we're experiencing a long drought here in California, and nearby states.

It's been an interesting problem from a systems perspective, particularly when the system being examined includes politics, really old water rights, and staple food items for other nations.

And you may have heard about the economics of almonds.  It takes a lot of water to grow almonds. And, almonds have been a highly profitable crop for farmers. So they've been planting more almonds, and using more water (by drilling, which isn't regulated)...

I love California, but since moving here in 2000 I've noted that one of our most popular cultural exports seems to be nationwide economic bubbles (aka "irrational exuberance").  There are a lot of great inspect/adapt experiments that happen in this gigantic petri dish of innovation, but when an experiment fails, we tend to try it again, just in a different sector.  The dot-BOMB practically led to the housing bubble here in CA.

The "good" news is that, when faced with an existential crisis, people start to think in terms of the larger systems they live in, and are willing to make personal sacrifices for the health of the overall system.  This article, particularly page 2, hints at longer-term systems-thinking. Apparently some Californians are discovering that chasing profits can be quite unprofitable.
It's PersonalThe title of this article caught my attention. (It was clearly designed to do so.) Since I was already thinking about water-usage and almonds, I assumed that this was going to appeal to liberal guilt. Fortunately, it's more about the economics of selling what amounts to little more than flavored vitamin water.

I like eating almonds. They're one of the world's "superfoods":  Nutrient-dense, little processing, very tasty.  Was I going to curb my almond consumption?

But remember that organic farmer in the Slate article who is planting almonds where he used to graze dairy cows?, Intended and OtherwiseThis is not a Californian problem, but a national one, as the Slate article makes evident.

California is the nation’s leading producer of almonds, avocados, broccoli, carrots, cauliflower, grapes, lettuce, milk, onions, peppers, spinach, tomatoes, walnuts, and dozens of other commodities. One way to try to get this system to stabilize is to consume fewer water-intensive resources. Of course, abrupt changes in demand would be painful for the system, as well. Replacing flood irrigation with drip irrigation takes a lot of effort, and farmers cannot simply plow over a cash crop in the middle of growing season.

And there will surely be those unintended consequences that we cannot predict.  Systems are tricky that way.

But the U.S. has been through similar droughts before, and we can weather the dry weather (in the West), only together.  (Yeah, if only there were an efficient way for us to move megatons of snow from the inundated East coast to the bone-dry West coast! :-)

Adopt a Californian

My colleagues and I are asking you to voluntarily reduce the amount of water-intensive drought-region-grown products you consume.  Be creative, and choose something that will have an impact (however small) and that you can personally maintain without going through severe withdrawals.

We're looking forward to seeing what the crowdsourced experience of Agile, Scrum, Lean, Theory of Constraints, and Systems Thinking practitioners can accomplish.

And we'd enjoy seeing your pledge on social media (Facebook, Twitter, LinkedIn, Google+, etc.), so please include the hashtag #AdoptACalifornian.  Here's a sample:

I commit to eating less red meat so @agilecoach @tptman and other friends may have fewer problems with California drought #AdoptACalifornian
— Bob Hartman (@AgileBob) April 18, 2015
I'm addicted to dairy.  I drink about 1/2 gallon of nonfat milk a day.  Yeah.  Addicted.  I'm going to try to replace some of that with plain water, and homemade rice milk (not almond, not soy). Hopefully, that's the optimal way to obtain water for my metabolism without wasting water systemically.  (Let me know if you know otherwise.)  So that's my #AdoptACalifornian pledge for all my Bay Area neighbors.

Categories: Blogs


When I was young, I had a riding lawn mower. We had a big yard out in the suburbs and the riding mower made the job quicker. Today I live closer to downtown in a house with a smaller yard. I’m currently using an old fashion reel mower…no motor, just foot power to make it work. For the yard I have, it’s all I need.
With all the technology around us, it’s easy to get caught up in the latest thing. Tools can make us more effective, but sometimes they can be distractions. 
Take project management tools. There are a plethora of them around and I have used them effectively on projects. But I have also run projects with just a white board and stack of post-it notes, not letting the technology get in the way of interacting with my team.
The Manifesto for Agile Software Development says it should be “Individuals and Interactions over Process and Tools” so ask yourself if the tool you are considering is going to help you or could it just be another distraction? Put another way, A fool with a tool is still a fool."
Categories: Blogs

5 Things Agile Leaders Must Do

Learn more about our Scrum and Agile training sessions on

From the full article “5 Things Agile Leaders Must Do“:

  1. Uphold self-organization.
  2. Formalize Agile roles.
  3. Understand that Scrum is not the only Agile method.
  4. Stop up-front planning.
  5. Lead by example.

Consider enrolling in our Scrum and Enterprise Agile for Executives ½ day seminar in Toronto.

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

Knowledge Sharing

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