Skip to content

Feed aggregator

10 Personal Productivity Tools from Agile Results

J.D. Meier's Blog - Fri, 11/27/2015 - 00:38

“Great acts are made up of small deeds.“ -- Lao Tzu

The best productivity tools are the ones you actually use and get results.

I'll share some quick personal productivity tools from Agile Results, introduced in the book, Getting Results the Agile Way.

Agile Results is a Personal Results System for work and life, and it's all about how to use your best energy for your best results.

With that in mind, here are some quick productivity tools you can use to think better, feel better, and do better, while getting results better, faster, and easier with more fun ...


Think in terms of Three Wins each day, each week, each month, each year.

You can apply the Rule of 3 to life. Rather than get overwhelmed by your tasks, choose three things you want to accomplish today. This puts you in control. If nothing else, it gives you a very simple way to focus for the day. This will help you get on track and practice the art of ruthless prioritization.

Consider the energy you have, what's the most important, what's the most valuable, and what would actually feel like a win for you and build momentum.

To get started, right here, right now, simply write down on paper the three things you want to achieve today.


The Monday Vision, Daily Outcomes, and Friday Reflection pattern is a simple habit for daily and weekly results.

Monday Vision - On Monday, identify Three Wins that you want for the week.  Imagine if it was Friday and you were looking back on your week, what are three results that you would be proud of?  This helps you have create a simple vision for your week.

Daily Wins - Get a Fresh Start each day.  Each day, identify Three Wins that you want for the day.  First thing in the morning, before you dive into the hustle and the bustle, step back.  Take the balcony view for your day and identify Three Wins that you want to accomplish.  This helps you create a simple vision for your day.  You can imagine three scenes from your day -- morning, noon and night -- or whatever works for you.

One way to stay balanced here is to ask yourself both, "What do I want to accomplish?", and "What are the key things that if I don't get done ... I'm screwed?"

Friday Reflection -- On each Friday, reflect on your week.  To do this, ask yourself two questions:

“What are 3 things going well?”

“What are 3 things to improve?”

You'll find that either you are either focusing on the wrong things, getting distracted, or biting off more than you can chew.  Use what you learn here as input into next week's Monday Vision, Daily Wins, Friday Reflection. 

The real power of Friday Reflection is that you acknowledge and appreciate your Personal Victories.  If you gave your all during your workout, hats off to you.  If you pushed a bit harder to really nail your presentation, great job.

It's also a simple way to "put a bow" on your results for the week.  Now, if your manager or somebody were to ask you what you accomplished for the week, you have a simple story of Three Wins.


Hot Spots are a simple metaphor for thinking about what’s important.

Think of your life like a heat map.

Start with a simple set of categories:

  1. Mind
  2. Body
  3. Emotions
  4. Career
  5. Finance
  6. Relationships
  7. Fun

Where do you need to spend more time or less time?

The Hot Spot categories support each other and they are connected, and in some cases overlapping.  But they give you a very quick way to explore an area of your life. 

It's hard to do well at work if you're having issues with relationships.  And the surprise for a lot of people is how if they take better care of their body, work gets a lot easier, and they improve their mind and emotions. 


The Growth Mindset is a learning mindset.

Instead of a static view of things, you approach things as experiments to learn and explore.  Failure isn't final.  Failure isn't fatal.  Instead, find the lesson and change your approach.

By adopting a Growth Mindset, you get better and better over time.  You don't say, "I'm no good at that."  You say, "I'm getting better at that." or "I'm learning."

With a Growth Mindset and a focus on continuous learning, you turn your days into learning opportunities.  This helps you keep your motivation going and your energy strong.

Life-long Learners last longer :)


Timeboxing is a way to set a time "budget."  This helps you avoid spending too much time on something, or over-investing when it's diminishing returns.

For a lot of people, they find they can focus in short-batches.  They can't focus indefinitely, but if they know they only have to work on something for say 20-minutes, it helps them fully focus on the task at hand.

If you've heard of the Pomodoro Technique, this is an example.  Set a time limit for a task, and work on the task until the buzzer goes off.

I use Timeboxing at multiple levels.  I might Timebox a mini-project to a week or a month, rather than let it go on forever "until it is done."  By using a Timebox, I create a sense of urgency and I give myself a finish line.  That's a real key to staying motivated and refueling your momentum.

Timeboxing can help you improve your productivity in a very simple way. For example, rather than try to figure out how long something might take, start by figuring out how much time you want to invest in it. Identify up front, at what point is it diminishing return. This will help you cut your losses and figure out how to optimize your time.


Each week spend more time in your strengths, and less time in your weaknesses.

Push activities that make you weak to the first part of your day. By doing your Worst Things First, you create a glide path for the rest of the day. This is like Brian Tracy's Eat that Frog.

Set limits.  Stuff the things that make you weak into a Timebox. For example, if the stuff that makes you weak is taking more than 20 percent of your day, then find a way to keep it within that 20 percent boundary. This might mean limiting the time or quantity.

Sometimes you just can't get rid of the things that make you weak; in that case, balance it with more things that energize you and make you strong.

Apply this to your week too. Push the toughest things that drain you to the start of the week to create a glide path. Do the same with people. Spend more time with people that make you strong and less time with people that make you weak. Be careful not to confuse the things that make you weak with challenges that will actually make you stronger. Grow yourself stronger over time.


Pick one thing to improve for the month.

Each month, pick something new; this gives you a chance to cycle through 12 things over the year. Or if necessary, you can always repeat a sprint.

The idea is that 30 days is enough time to experiment with your results throughout the month. Because you might not see progress in the first couple of weeks while you’re learning, a month is a good chunk of time to check your progress.

This is especially helpful if you find that you start a bunch of things but never finish.  Just focus this month on the one thing, and then next month, you can focus on the other thing, and so on.

Each month is a Fresh Start and you get to pick a theme for the month so that everything you do accrues to something bigger.


This is perhaps one of the most impactful ways to improve your productivity.

Pair with people that complement your strengths.

Pair up or team up with others that compliment your preferred patterns.  If you are a Starter, pair up with a Finisher.  If you are a Thinker, pair up with a Doer.  If you are a Maximizer, pair up with a Simplifier.

Anything, and I mean anything, that you want to do better or faster, there is somebody in the world that lives and breathes it.  And, in my experience, they are more than happy to teach you, if you just ask.

The best way to Pair Up is to find somebody where it's a two-way exchange of value and you both get something out of it.  To do this, it helps when you really know what you bring to the table, so it's clear why you are Pairing Up.

Ask yourself, who can you team up with to get better results?


Chances are you have certain hours in the day or night when you are able to accomplish more.

These are your personal Power Hours.

Guard your Power Hours so they are available to you and try to push the bulk of your productivity within these Timeboxes. This maximizes your results while optimizing your time.

You might find you only have a few great hours during the week where you feel you produce effective and efficient results. You may even feel “in the zone” or in your “flow” state. Gradually increase the number of Power Hours you have. You can build a powerful day, or powerful week, one power hour at a time. If you know you only have three Power Hours in a 40-hour week, see if you can set yourself up to have five Power Hours.


Your Creative Hours are those times during the week where you feel you are at your creative best.

This might be a Saturday morning or a Tuesday night, or maybe during weekday afternoons.

The key is to find those times where you have enough creative space, to do your creative work.

Just like adding power hours, you might benefit from adding more creative hours. Count how many creative hours you have during the week. If it’s not enough, schedule more and set yourself up so that they truly are creative hours. If you’re the creative type, this will be especially important. If you don’t think of yourself as very creative, then simply use your Creative Hours to explore any challenges in your life or to innovate.

There is so much more, but I find that if you play around with these Personal Productivity Tools, you can very quickly get better results in work and life.

If you don't know where to start, start simple:

Ask yourself what are the Three Wins you want to accomplish today, and write those done on a piece of paper.

That's it -- You're doing Agile Results.

Categories: Blogs

Building High-Performing Organizations Game played at GOAT15

Notes from a Tool User - Mark Levison - Thu, 11/26/2015 - 18:16

Agile Pain Relief was proud to be a major sponsor for the Gatineau-Ottawa Agile Tour for yet another year, and Mark debuted a brand new game as part of his GOAT15 presentation.

“Beyond Scrum: Building High-Performing Organizations – a game for Managers, ScrumMasters and Product Owners” is a board game that builds on the success of last year’s “Building High-Performing Teams“.

Last year’s game focused on building high-performance Teams and the tradeoffs between delivering value and improving productivity.  This year’s game focuses on building high-performance Organizations, and explores options for an Organization to understand itself and the current state of the work, and then bring about real, ongoing change.

Game Style:

Board Game with a simple Portfolio Kanban board as our playing surface. The playing cards are Kanban cards that represent our Product Backlog, as well as other cards that represent personalities and challenges that Organizations must navigate.

High Performing Organizations Game Board

Game Tables:

Each table will represent one Organization that is trying to improve.

The players on each team will take on the roles of Senior Management, the ScrumMaster, and Product Owner. Each table starts off with one Scrum team represented and several Managers, and may expect through game play to additional teams. Anywhere from 4-9 players. Effectively they will compose an Organizational Improvement Team.

Each player will receive a role description that explains the character that they should play. Real companies have politics, and people often have competing agendas – the player sheets will help simulate that.

Play will focus on the challenges faced in any modern mid to large-sized company attempting to be Agile, such as:

  • Short-term client demands and weathervaning executives
  • Belief that if we just demand that the teams work harder, they can and will
  • Production support issues
  • Regression problems
  • Fundamental misunderstandings of Agile by the executives
  • Features delivered that don’t satisfy customers

The game is won, not by producing the most features, but by delighting customers. In this case customer happiness is determined by whether or not they pay you for the features you produce.

Players will learn much about Portfolio Kanban and Portfolio Management. They will also get an introduction to Systems Thinking, and Organizational Improvement. As a result, they will have an introduction as to what it will take to grow their Organization’s performance. The game is backed by the series of blog posts Mark has been writing this year – Scrum Alone is Not Enough.


This is a budget-based game – in any round the players can invest in Stories, Improvements for their team, or Improvements for all teams. In each round, the Organizational Improvement team will gain access to a growing list of tools (some good, some bad) to help ‘fix’ the problems that come up.

The Results:

Along with a lot of laughter from all participants, several discoveries and feedback comments were made with ~70 people playing the game at its debut at GOAT15:

  • One team went bankrupt, and others saw the importance of building things to build resilience early (e.g. cross-skilling, walking the Portfolio Kanban with the team).
  • It was noted that personalities have a huge effect on the productivity of meetings!
  • The initial rule of rolling dice for how much work your team achieved in a round added complication without a lot of extra value. We’ve revised the game to have a simpler version, and moved this feature to an advanced section.
  • It was suggested that we make it more clear in the rules sheet that you only start the game with one team – which we’ve now done.
  • Some suggested that the game cards should show only the mechanical effects and not explain the why, instead leaving that to the accompanying notes and game discussion. We’ll consider this for future versions.
  • In the presentation, showing the areas of the Kanban board being used would have helped make clear which part was being referred to.

Thanks to everyone who played the game in its first public session. Changes from this playing will influence the game’s future.

We’d Love  Your Feedback

We invite you to download the game materials here and try it with your own team.

Please let us know your comments and suggestions, so we can consider them for future improvements. And send us a photo of your team playing the game!


Related Reference Links:

Map your Kanban wall – Mark hinted during the game that it would take some time and effort to map your wall. This video and accompanying text explain how:

Prosocial bonuses – the alternative to team bonuses that we tried in the game:

More reference material from discussions during game play:

Additional References:

Categories: Blogs

SonarQube 5.2 in Screenshots

Sonar - Thu, 11/26/2015 - 15:14

The team is proud to announce the biggest release ever of the SonarQube server, version 5.2, which includes the second-most-anticipated feature ever: code scanners no longer access the database! In brief, this version features:

  • Scanners no longer access the database
  • Enhanced monitoring
  • Better issue management
  • Improved UI for global admin
  • Also worth noting

Scanners no longer access the database

In a significant, fundamental change, this version breaks the direct ties from the SonarQube Scanners (SonarQube Runner, Maven, Gradle, …) to the SonarQube database. From this version forward, it is no longer necessary to hand out your SonarQube database credentials to would-be analyzers, and if they’re still included in your analysis parameters, you’ll see warnings in the log:

Breaking the database connection means you’re now free to execute analysis from your CI services like travis-ci, appveyor, VSO Build, and so on without biting your nails over database security. Instead, scanners now submit analysis reports to the server, and the server processes them asynchronously. This means that analysis results are not available in the Web application right after the scanner has finished its execution, it can take some time depending on the load on the server:

But it also means that it’s no longer required to have a fat network connection between the machines analysis runs on and the database. Now you can arrange those machines on your network based solely on your own criteria.

As soon as an analysis report is sent to the server, the status of the report is displayed on the dashboard of the corresponding project:

Enhanced monitoring

Because more processing is done on server-side, more information is available server-side to monitor and understand what’s going on in SonarQube. First, the former “Analysis Reports” page has been renamed “Background Tasks” and redesigned to offer far more features, including access to the analysis report processing logs:

The page is available at project administration level too:

Server logs are also now accessible from the UI, and it’s possible to dynamically change the server log level (it reverts automatically on restart):

Better issue management

Continuing the theme of more and better information, the reporting of issues has also improved in this version. First, is the ability to have more precise issue highlighting, additional issue locations, and additional messages:

The additional highlights and messages are attached to the issues, so you have to select an issue to see its “extras”:

Of course, the platform just makes these things possible; the language plugins have to support them before you’ll see these effects. So far, you can see additional locations and messages in select rules in the Java plugin.

Another improvement is the ability to display issues by count or technical debt:

As well as a new entry page for issues with quick links to default and saved issue filters:

Speaking of filters, there’s a new issue filter widget with a wide variety of display options, so you can put the results of any search directly on your dashboard:

Wrapping up the topic of issues, we’ve improved notifications, with a new “My New Issues” notification that tells you only about what’s relevant to you, and we’ve added the ability to define a default issue assignee on a project. This account will be used for every new issue that SonarQube can’t assign automatically based on the SCM information.

Improved UI for global admin

A number of pages have been rewritten in this version for a more consistent user experience. The one available to everyone is the Quality Profiles page:

Beyond that, many administrative pages have been rewritten, including all the security pages:

As well as the Update Center:

And the Project Management page:

As a side-effect of these rewrites, web services are now available for all the types of data required to feed these pages. Check your server’s api_documentation for details, or use Nemo’s for a quick reference.

Also worth noting

As a side-effect of the ties between analysis and the database, plugins that do data manipulation beyond simply gleaning raw numbers and issues directly from source files will probably need to be rewritten because the API’s have changed, and such processing must now be done server-side.

All design-related features were dropped in this version (see SONAR-6553 for details), including Package Tangle Index and related metrics.

Also gone in 5.2, but slated to reappear in 5.3 is cross-module/project duplication detection. Why? We simply ran out of time.

That’s All, Folks!

Time now to download the new version and try it out. But don’t forget to read the installation or upgrade guide.

Categories: Open Source

Agile Pracitioners Israel, Tel Aviv, Israel, January 26-27 2016

Scrum Expert - Thu, 11/26/2015 - 14:00
Agile Practitioners conference is the first community-led Agile and Scrum conference organized in Israel. The first day is dedicated to workshops and the second day will be full of interesting presentations from local and international Agile software development and Scrum project management experts. In the agenda of the Agile Practitioners you can find topics like “The Spider-man antidote to the anti-pattern of agile leaders”, “How to ...
Categories: Communities

Scheduling containers and more with Nomad

Xebia Blog - Thu, 11/26/2015 - 12:18

Specifically for the Dutch Docker Day on the 20th of November, HashiCorp released version 0.2.0 of Nomad which has some awesome features such as service discovery by integrating with Consul, the system scheduler and restart policies.  HashiCorp worked hard to release version 0.2.0 on 18th of November and we pushed ourselves to release a self-paced, hands-on workshop. If you would like to explore and play with these latest features of Nomad, go check out the workshop over at

In this blog post (or as I experienced it: roller coaster ride), you will catch a glimpse of the work that went into creating the workshop.

Last friday, November the 20th, was the first edition of the Dutch Docker Day where I helped prepare a workshop about "scheduling containers and more with Nomad". It was a great experience where attendees got to play with the new features included in 0.2.0, which nearly didn't make it into the workshop.


When HashiCorp released Nomad during their HashiConf event at the end of September, I was really excited as they always produce high quality tools with great user experience. As soon as the binary was available I downloaded it and tried to set up a cluster to see how it compared to some of it's competitors. The first release already had a lot of potential but also a lot of problems. For instance: when a container failed, Nomad would report it dead, but take no action; restart policies were still but a dream.

There were a lot of awesome features in store for the future of Nomad: integration with Consul, system jobs, batch jobs, restart policies, etc. Imagine all possible integrations with other HashiCorp tools! I was sold. So when I was asked to prepare a workshop for the Dutch Docker Day I jumped at the opportunity to get better acquainted with Nomad. The idea was that the attendees of the workshop, since it was a pretty new product and had some quirks, would go on an explorative journey into the far reaches of the scheduler and together find it's treasures and dark secrets.

Time went by and the workshop was taking shape nicely. We have a nice setup with a cluster of machines that automatically bootstrap the Nomad cluster and set up it's basic configuration. We were told that there would be a new version released before the Dutch Docker Day but nothing appeared, until the day before the event. I was both excited and terrified! The HashiCorp team worked long hours to get the new release of Nomad done in time for the Dutch Docker Day so Armon Dadgar, the CTO of HashiCorp and original creator of Nomad, could present the new features during his talk. This of course is a great thing, except for the fact that the workshop was entirely aimed at 0.1.2 and we had none of these new features incorporated into our Vagrant box. Were we going to throw all our work overboard and just start over, the night before the event?

“Immediately following the initial release of Nomad 0.1, we knew we wanted to get Nomad 0.2 and all its enhancements into the hands of our users by Dutch Docker Day. The team put in a huge effort over the course of a month and a half to get all the new features done and to a polish people expect of HashiCorp products. Leading up to the release we ran into one crazy bug after another (surprisingly all related to serialization). After intense debugging we got it to the fit and polish we wanted the night before at 3 AM! Once the website docs were updated and the blog post written, we released Nomad 0.2. The experience was very exciting but also exhausting! We are very happy with how it turned out and hope the users are too!„

- Alex Dadgar, HashiCorp Engineer working on Nomad

It took until late in the evening to get an updated Vagrant box with a bootstrapped Consul cluster and the new Nomad version, in order to showcase the auto discovery feature and Consul integration that 0.2.0 added. However, the slides for the workshop were still referencing the problems we encountered when trying out the 0.1.0 and 0.1.2 release, so all the slides and statements we had made about things not working or being released in the future had to be aligned with the fixes and improvements that came with the new release. After some hours of hectic editing during the morning of the event, the slides were finally updated and showcased all the glorious new features!

Nomad simplifies operations by supporting blue/green deployments, automatically handling machine failures, and providing a single workflow to deploy applications.

The new features they added in this release and the amount of fixes and improvements is staggering. In order to discover services there is no longer a need for extra tools such as Registrator, and your services are now automatically registered and deregistered as soon as they are started and stopped (which I first thought was a bug, cause I wasn't used to Nomad actually restarting my dead containers). The system scheduler is another feature I've been missing in other schedulers for a while, as it makes it possible to easily schedule services (such as Consul or Sysdig) on all of the eligible nodes in the cluster.

Feature 0.1.2 0.2.0 Service scheduler Schedule a long lived job. Y Y Batch scheduler Schedule batch workloads. Y Y System scheduler Schedule a long lived job on every eligible node. N Y Service discovery Discover launched services in Consul. N Y Restart policies If and how to restart a service when it fails. N Y Distinct host constraint Ensure that Task Groups are running on distinct clients. N Y Raw exec driver Run exec jobs without jailing them. N Y Rkt driver A driver for running containers with Rkt. N Y External artifacts Download external artifacts to execute for Exec and Raw exec drivers. N Y   And numerous fixes/improvements were added to 0.2.0

If you would like to follow the self-paced workshop by yourself, you can find the slides, machines and scripts for the workshop at together with the other workshops of the event. Please let me know your experiences, so the workshop can be improved over time!

I would like to thank the HashiCorp team for their amazing work on the 0.2.0 release, the speed at which they have added so many great new features and improved the stability is incredible.

It was a lot of fun preparing the workshop for the Dutch Docker Day. Working with bleeding edge technologies is always a great way to really get to know it's inner workings and quirks, and I would recommend it to anyone, just be prepared to do some last-minute work ; )

Categories: Companies

Agile Benefits Management

Leading Answers - Mike Griffiths - Thu, 11/26/2015 - 05:43
Benefits are why we undertake projects. Projects are expensive to undertake and have a risk of failure. So, we need to get benefits from them, or at least think we will get benefits from them, to start projects in the... Mike Griffiths
Categories: Blogs

Lean Coffee at #AgileTD

Growing Agile - Wed, 11/25/2015 - 14:54
At Agile Testing Days I was lucky enough to attend all 3 days of Lean Coffee – hosted by Lisa Crispin and Janet Gregory. I love Lean Coffees as they are only an hour, I usually get to meet some nice people and the topics are interesting. I also have a short attention span so […]
Categories: Companies

A simple framework to understand the changes your organization is facing

Bruno Collet - Agility and Governance - Wed, 11/25/2015 - 03:47
As the business environment becomes more turbulent, organizations must learn to anticipate and adapt better and faster. However organizations are not equal in the face of change. Whereas a telecommunications company in a developing economy might have to re-invent its strategy twice a year, a pulp and paper company in a stable economy might accurately predict the next three years.

Before asking how change-ready your organization is, take a step back to understand how much change and what kind of change it is facing.

The VUCA concept provides a good starting point to look at an organization's context and how likely it is to evolve. It defines four characteristics of a changing environment: Volatile, Uncertain, Complex and Ambiguous. For a great summary of VUCA, read Harvard Business Review's What VUCA Really Means for You.


Unfortunately, while VUCA is intellectually compelling, it is too abstract to use as such for assessing a changing environment.
A framework based on VUCA and environment forces
Let's see how we can elaborate on VUCA to build a simple but actionable framework. The framework below combines VUCA factors with environment forces and shows an example of change for each combination. Typical environment forces used in the framework are Competition, Customer expectations, Talent, Technology, Partners & suppliers, and Regulation.
An example for Volatility of Competition might be: "In our industry, some competitors frequently do deep discounts, which can affect our sales significantly but temporarily."
Click to enlarge
The framework calls on people's anticipative thinking and collective intelligence. Respondents are asked to rate each combination of VUCA factor / environment force for the likelihood of changes that might affect the organization a few years down the road. The framework questions can be delivered through one-to-one interviews, workshops, or surveys. I have found one-to-one interviews and surveys more effective in a first pass because they make it easier to understand personal concerns, and because they show gaps of perception between functions and levels. Whereas workshops are more effective in a second stage to make various perceptions converge to a shared picture of the changing environment and generate a collective sense of urgency.
Additional guidelines to use this framework successfully
  • If you know the organization in question, tailor the examples to be more relevant. (framework above is a generic version)
  • You can use this framework for a specific area of the organization. The environment is therefore anything that is outside this area.
  • The quality of the assessment depends greatly on the people you select to answer these questions. Select the minimum number of people who are representative of the different functions and levels of your organization.
  • Ask the question for each combination to each respondent on a simple scale such as low / medium / high. Don't try making it a scientific measurement. The goal is to understand just enough to focus further efforts where it matters the most.

Now what?
This simple framework is not meant to replace a comprehensive diagnosis. It helps understand, with minimal investment, how much change your organization is facing, what type of changes and in which areas. It also helps gain attention from key stakeholders. If you decide to go further, it points to areas of improvements and helps identify potential levers such as people, processes, or structures.
Categories: Blogs

Rerun Jenkins Builds

Some consultants at our office needed to be able to roll back a Jenkins project that deployed to staging and production sites in case of an issue. The project had been setup to allow for a typical git checkout and then ended up using a php build tool, phing, to essentially rsync up to the servers.

Turns out ‘Parameterized Builds’ was able to resolve this. It took just a few steps:

  • Click ‘Configure’ on the project.
  • Check ‘This build is parameterized’.
  • Add a String Parameter with the name GIT_COMMIT and a default of ‘master’
  • Under Git > Branches to build, add the parameter as $GIT_COMMIT
  • Save

This allows you to specify the commit SHA for each release. If you need to roll back you just run it with the specified commit SHA. This can be configured to use git tags as well. Inspiration of this came from this post.

Categories: Blogs

Agile Economics: Contracts, Budgets, Capitalization

Scrum Expert - Tue, 11/24/2015 - 20:57
How much does one story point cost? Is Sprint 0 an expense or an asset? Can you run Scrum with a fixed-cost contract? Agile challenges the existing approach to financial aspects of running projects, that is budgeting, forecasting, financial planning and vendor contracts. Applying new financial models becomes increasingly important for larger organisations adopting Agile. While they are going through an Agile transformation, they also need ...
Categories: Communities

The Project Manager Fear

TV Agile - Tue, 11/24/2015 - 19:41
Project fear, not dissimilar to imposter syndrome, tends to affect all project leaders at some point (or many points) in their career. This session tackles project fear by fully defining it, investigating its roots, noting its symptoms, and ultimately discussing a number of successful coping mechanisms. Conference organizer: Video producer:
Categories: Blogs

CA Technologies Releases Agile Management Portfolio

Scrum Expert - Tue, 11/24/2015 - 17:55
CA Technologies has released an Agile Management portfolio that fuses strategy, investment and portfolio planning technology with agile coaching expertise to help enterprises succeed in the application economy. The Agile Management portfolio combines select software and service components from CA and Rally, which CA acquired in July 2015. Agile Management capabilities are available now, including a new release of CA Project & Portfolio Management (CA PPM) ...
Categories: Communities

jq: Cannot iterate over number / string and number cannot be added

Mark Needham - Tue, 11/24/2015 - 02:12

In my continued parsing of’s JSON API I wanted to extract some information from the following JSON file:

$ head -n40 data/members/18313232.json
    "status": "active",
    "city": "London",
    "name": ". .",
    "other_services": {},
    "country": "gb",
    "topics": [],
    "lon": -0.13,
    "joined": 1438866605000,
    "id": 92951932,
    "state": "17",
    "link": "",
    "photo": {
      "thumb_link": "",
      "photo_id": 250896203,
      "highres_link": "",
      "photo_link": ""
    "lat": 51.49,
    "visited": 1446745707000,
    "self": {
      "common": {}
    "status": "active",
    "city": "London",
    "name": "Abdelkader Idryssy",
    "other_services": {},
    "country": "gb",
    "topics": [
        "name": "Weekend Adventures",
        "urlkey": "weekend-adventures",
        "id": 16438
        "name": "Community Building",
        "urlkey": "community-building",

In particular I want to extract the member’s id, name, join date and the ids of topics they’re interested in. I started with the following jq query to try and extract those attributes:

$ jq -r '.[] | [.id, .name, .joined, (.topics[] | .id | join(";"))] | @csv' data/members/18313232.json
Cannot iterate over number (16438)

Annoyingly this treats topic ids on an individual basis rather than as an array as I wanted. I tweaked the query to the following with no luck:

$ jq -r '.[] | [.id, .name, .joined, (.topics[].id | join(";"))] | @csv' data/members/18313232.json
Cannot iterate over number (16438)

As a guess I decided to wrap ‘.topics[].id’ in an array literal to see if it had any impact:

$ jq -r '.[] | [.id, .name, .joined, ([.topics[].id] | join(";"))] | @csv' data/members/18313232.json
92951932,". .",1438866605000,""
jq: error (at data/members/18313232.json:60013): string ("") and number (16438) cannot be added

Woot! A different error message at least and this one seems to be due to a type mismatch between the string we want to end up with and the array of numbers that we currently have.

We can cast our way to victory with the ‘tostring’ function:

$ jq -r '.[] | [.id, .name, .joined, ([.topics[].id | tostring] | join(";"))] | @csv' data/members/18313232.json
92951932,". .",1438866605000,""
193866304,"Abdelkader Idryssy",1445195325000,"16438;20727;15401;9760;20246;20923;3336;2767;242;58259;4417;1789;10454;20274;10232;563;25375;16433;15187;17635;26273;21808;933;7789;23884;16212;144477;15322;21067;3833;108403;20221;1201;182;15083;9696;4377;15360;18296;15121;17703;10161;1322;3880;18333;3485;15585;44584;18692;21681"
28643052,"Abhishek Chanda",1439688955000,"646052;520302;15167;563;65735;537492;646072;537502;24959;1025832;8599;31197;24410;26118;10579;1064;189;48471;16216;18062;33089;107633;46831;20479;1423042;86258;21441;3833;21681;188;9696;58162;20398;113032;18060;29971;55324;30928;15261;58259;638;16475;27591;10107;242;109595;10470;26384;72514;1461192"
39523062,"Adam Kinder-Jones",1438677474000,"70576;21549;3833;42277;164111;21522;93380;48471;15167;189;563;25435;87614;9696;18062;58162;10579;21681;19882;108403;128595;15582;7029"
194119823,"Adam Lewis",1444867994000,"10209"
14847001,"Adam Rogers",1422917313000,""
87709042,"Adele Green",1436867381000,"15167;18062;102811;9696;30928;18060;78565;189;7029;48471;127567;10579;58162;563;3833;16216;21441;37708;209821;15401;59325;31792;21836;21900;984862;15720;17703;96823;4422;85951;87614;37428;2260;827;121802;19672;38660;84325;118991;135612;10464;1454542;17936;21549;21520;17628;148303;20398;66339;29661"
11497937,"Adrian Bridgett",1421067940000,"30372;15046;25375;638;498;933;374;27591;18062;18060;15167;10581;16438;15672;1998;1273;713;26333;15099;15117;4422;15892;242;142180;563;31197;20479;1502;131178;15018;43256;58259;1201;7319;15940;223;8652;66493;15029;18528;23274;9696;128595;21681;17558;50709;113737"
14151190,"adrian lawrence",1437142198000,"7029;78565;659;85951;15582;48471;9696;128595;563;10579;3833;101960;16137;1973;78566;206;223;21441;16216;108403;21681;186;1998;15731;17703;15043;16613;17885;53531;48375;16615;19646;62326;49954;933;22268;19243;37381;102811;30928;455;10358;73511;127567;106382;16573;36229;781;23981;1954"
183557824,"Adrien Pujol",1421882756000,"108403;563;9696;21681;188;24410;1064;32743;124668;15472;21123;1486432;1500742;87614;46831;1454542;46810;166000;126177;110474"
Categories: Blogs

Example Mapping - Steering the conversation

Xebia Blog - Mon, 11/23/2015 - 20:14

People who are familiar with BDD and ATDD already know how useful the three amigos (product owner, tester and developer) session is for talking about what the system under development is supposed to do. But somehow these refinement sessions seem to drain the group's energy. One of the problems I see is not having a clear structure for conversations.

Example Mapping is a simple technique that can steer the conversation into breaking down any product backlog items within 30 minutes.

The Three Amigos

Example Mapping is best used in so called Three Amigo Sessions. The purpose of this session is to create a common understanding of the requirements and a shared vocabulary across product owner and the rest of the team. During this session the product owner shares every user story by explaining the need for change in a product. It is essential that the conversation has multiple points of view. Testers and developers identify missing requirements or edge cases and are addressed by describing accepted behaviour, before a feature is considered ready for development.

In order to help you steer the conversations, here is a list of guidelines for Three Amigos Sessions:

  • Empathy: Make sure the team has the capability to help each other understand the requirements. Without empathy and the room for it, you are lost.
  • Common understanding of the domain: Make sure that the team uses the same vocabulary (digital of physical) and speaks the same domain language.
  • Think big, but act small: Make sure all user stories are small and ready enough to make impact
  • Rules and examples: Make sure every user story explains the specification with rules and scenarios / examples.
Example mapping

Basic ingredients for Example Mapping are curiosity and a pack of post-it notes containing the following colours:

  • Yellow for defining user story
  • Red for defining questions
  • Blue for defining rules
  • Green for defining examples

Using the following steps can help you steer the conversations towards accepted behaviour of the system under development:

  1. Understanding the problem
    Let the product owner start by writing down the user story on a yellow post-it note and have him explain the need for change in the product. The product owner should help the team understand the problem.
  2. Challenge the problem by asking questions
    Once the team has understood the problem, the team challenges the problem by asking questions. Collect all the questions by writing them down starting with "What if ... " on red post-it notes. Place them on the right side of the user story (yellow) post-it note. We will treat this post-it note as a ticket for a specific and focussed discussion.
  3. Identifying rules
    The key here is to identify rules for every given answer (steered from the red question post-it notes). Extract rules from the answers and write them down on a blue post-it note. Place them below the user story (yellow) post-it note. This basically describes the acceptance criteria of a user story. Make sure that every rule can be discussed separately. The single responsibility principle and separation of concerns should be applied.
  4. Describing situations with examples
    Once you have collected all the important rules of the user story, you collect all interesting situations / examples by writing them down on a green post-it note. Place them below the rule (blue) post-it note. Make sure that the team talks about examples focussed on one single rule. Steer the discussion by asking questions like: Have we reached the boundaries of the rule? What happens when the rule fails?
An example


Here in the given example above, the product owners requires a free shipping process. She wrote it down on a yellow post-it note. After collecting and answering questions, two rules were discussed and refined on blue post-it notes; shopping cart limit and the appearance of the free shipping banner on product pages. All further discussions were steered towards the appropriate rule. Two examples in the shopping cart limit were defined and one example for the free shipping banner on a green post-it notes. Besides steering the team in rule based discussions, the team also gets a clear overview of the scope for the first iteration of the requirement.

Getting everyone on the same page is the key to success here. Try it a couple of times and let me know how it went.


Categories: Companies

Your New Technical Skills

J.D. Meier's Blog - Mon, 11/23/2015 - 20:12

One of the struggles a developer faces when moving up the ladder is how to keep their technical skills.

If they are used to being a high-performing, individual contributor, and a technical go-to resource, this is especially challenging.


Because the job is different, now.

It’s no longer about how awesome your developer skills are.  Now it’s about bringing out the best from the people you manage, and hopefully *lead.*  Your job is now about creating a high-performing team.   It’s about growing more leaders.  It’s about being the oil and the glue.  The oil so that the team can work effectively, as friction-free as possible, and the glue, so that all the work connects together.

There’s a good book called What Got You Here, Won’t Get You There, by Marshall Goldsmith.  The book title sort of says it all, but the big idea is that if you take on a new management role, but continue to perform like an individual contributor, or at a lower level, don’t expect to be successful.

The irony is that most people will quickly default to doing what they do best, which is what got them to where they are.   But now the rules have changed, and they don’t adapt.  And as the saying goes, adapt or die.  It’s how a lot of careers end.

But not you.

While you will want to keep up your skills that got you to where you are, the real challenge is about adding new ones.   And, at first blush, they might just seem like “soft skills”, while you are used to learning “technical skills.”   Well, treat these at your new technical skills to learn.

Your new technical skills are:

  1. Building EQ (Emotional Intelligence) in teams
  2. Building High-Performance Teams
  3. Putting vision/mission/values in place
  4. Putting the execution model in place
  5. Directing and inspiring as appropriate – situational leadership – per employee
  6. Creating and leverage leadership opportunities and teachable moments
  7. Creating the right decision frameworks and flows and empowerment models
  8. Building a better business
  9. And doing thought-work in the space for the industry

I’ll leave this list at 9, so that it doesn’t become a 10 Top Skills to Learn to Advance Your Career post.

Emotional Intelligence as a Technical Skill

If you wonder how Emotional Intelligence can be a technical skill, I wish I could show you all the Mind Maps, the taxonomies, the techniques, the hard-core debates over the underlying principles, patterns, and practices, that I have seen many developers dive into over the years.

The good news is that Emotional Intelligence is a skill you can build.  I’ve seen many developers become first time managers and then work on their Emotional Intelligence skills and everything changes.  They become a better manager.  They become more influential.  They read a room better and know how to adapt themselves more effectively in any situation.  They know how to manage their emotions.  And they know how to inspire and delight others, instead of tick them off.

Along the lines of Emotional Intelligence, I should add Financial Intelligence to the mix.  So many developers and technologists would be more effective in the business arena, if they mastered the basics of Financial Intelligence.  There is actually a book called Financial Intelligence for IT Professionals.   It breaks down the basics of how to think in financial terms.   Innovation doesn’t fund itself.  Cool projects don’t fund themselves.  Technology is all fun and games until the money runs out.  But if you can show how technology helps the business, all of a sudden instead of being a cost or overhead, you are now part of the value chain, or at least the business can appreciate what you bring to the table.

Building High-Performance Teams as a Technical Skill

Building High-Performance Teams takes a lot of know-how.  It helps if you are already well grounded in how to ship stuff.  It really helps if you have some basic project management skills and you know how to see how the parts of the project come together as a whole.  It especially helps if you have a strong background in Agile methodologies like Kanban, Scrum, XP, etc.  While you don’t need to create Kanbans, its certainly helps if you get the idea of visualizing the workflow and reducing open work.  And, while you may not need to do Scrum per se, it helps if you get the idea behind a Product Backlog, a Sprint Backlog, and Sprints.  And while you may not need to do XP, it helps if you get the idea of sustainable pace, test-driven development, pairing, collective ownership, and an on-site customer. 

But the real key to building high-performance teams is actually about trust. 

Not trust as in “I trust that you’ll do that.”  

No.  It’s vulnerability-based trust, as in “I’ve got your back.”   This is what enables individuals on a team to go out on a limb, to try more, to do more, to become more.

Otherwise, they everybody has to watch out for their own backs, and they spend their days making sure they don’t get pushed off the boat or hanging from a limb, while somebody saws it off.   (See 10 Things Great Managers Do.)

And nothing beats a self-organizing team, where people sign-up for work (vs. get assigned work), where people play their position well, and help others play theirs.

Vision, Mission, Values as a Technical Skill

Vision, mission, and values are actually some of the greatest technical skills you can master, for yourself and for any people or teams you might lead, now or in the future.   So many people mix up vision and mission.

Here’s the deal:

Mission is the job.

Vision is where you want to go, now that you know what the job is.

And Values are what you express in actions in terms of what you reward.  Notice how I said actions, not words.  Too many people and teams say they value one thing, but their actions value another.

It’s one thing to go off and craft a vision, mission, and values that you want everybody to adhere to.  It’s another thing to co-create the future with a team, and create your vision, mission, and values, with everybody’s fingerprints on it.  But that’s how you get buy-in.   And getting buy-in, usually involves dealing with conflict (which is a whole other set of technical skills you can master.)  

When a leader can express a vision, mission, and values with clarity, they can inspire the people around them, bring out the best in people, create a high-performance culture, and accelerate results.

Execution as a Technical Skill

This is where the rubber meets the road.  There are so many great books on how to execute with skill.  One of my favorites is Flawless Execution.  And of the most insightful books on creating an effective execution model is Managing the Design Factory.

The main thing to master here is to be able to easily create a release schedule that optimizes resources and people, while flowing value to customers and stakeholders.

I know that’s boiling a lot down, but that’s the point.  To master execution, you need to be able to easily think about the challenges you are up against:  not enough time, not enough resources, not enough budget, not enough clarity, not enough customers, etc.

It’s a powerful thing when you can turn chaos into clarity and get the train leaving the station in a reliable way.

It’s hard to beat smart people shipping on a cadence, if they are always learning and always improving.

Situational Leadership as a Technical Skill

Sadly, this is one of the most common mistakes of new managers.  Seasoned ones, too.  They treat everybody on the team the same.  And they usually default to whatever they learned.   They either focus on motivating or they focus on directing.  And directing to the extreme, very quickly becomes micro-managing.

The big idea of Situational Leadership is to consider whether each person needs direction or motivation, or both.  

If you try to motivate somebody who is really looking for direction, you will both be frustrated.  Similarly, if you try to direct somebody who really is looking for motivation, it’s a quick spiral down.

There are many very good books on Situational Leadership and how to apply it in the real world.

Decision Making as a Technical Skill

This is where a lot of blood-shed happens.   This is where conflict thrives or dies.   Decision making is the bread-and-butter of today’s knowledge worker.  That’s what makes insight so valuable in a Digital Economy.  After all, what do you use the insight for?  To make better decisions.

It’s one thing for you to just make decisions.

But the real key here is how to create simple ways to deal with conflict and how to make better decisions as a group.   This includes how to avoid the pitfalls of groupthink.  It includes the ability to leverage the wisdom of the crowds.  It also includes the ability to influence and persuade with skill.  It includes the ability to balance connection with conviction.  It includes the ability to balance your Conflict Management Style with the Conflict Management Style of others.

Business as a Technical Skill

Business can be hard-core.   This isn’t so obvious if you deal with mediocre business people.  But when you interact with serious business leaders, you quickly understand how complicated, and technical, running a business and changing a business really is.

At the most fundamental level, the purpose of a business is to create a customer.

But even who you choose to serve as your “customer” is a strategic choice.

You can learn a lot about business by studying some of the great business challenges in the book, Case Interview Secrets, which is written by a former McKinsey consultant.

You can also learn a lot about business by studying which KPIs and business outcomes matter, in each industry, and by each business function.

It also helps to be able to quickly know how to whiteboard a value chain and be able to use some simple tools like SWOT analysis.  If you can really internalize Michael Porter’s mental models and toolset, then you will be ahead of many people in the business world.

Thoughtwork as a Technical Skill

There are many books and guides on how to be a leader in your field.   One of my favorites is, Lead the Field, by Earl Nightingale.  It’s an oldie, but goodie.

The real key is to be able to master ideation.  You need to be able to come up with ideas.   Probably the best technique I learned was long ago.   I simply set an idea quota.   In the book, ThinkerToys, by Michael Michalko, I learned that Thomas Edison set a quote to think up new ideas.  Success really is a numbers game.   Anyway, I started by writing one idea per note in my little yellow sticky pad.  The first week, I had a handful of ideas.   But once my mind was cleared by writing my ideas down, I was soon filling up multiple yellow sticky pads per week.

I very quickly went from having an innovation challenge to having an execution challenge.

So then I went back to the drawing board and focused on mastering execution as a technical skill Winking smile

Hopefully, if you are worried about how to keep growing your skills as you climb your corporate ladder, this will give you some food for thought.

Categories: Blogs

Real-World Kanban

In "Real-World Kanban," Mattias Skarin shares how Kanban can help boost engagement, teamwork and flow. Watch the webinar to learn how.

The post Real-World Kanban appeared first on Blog | LeanKit.

Categories: Companies

How Unified Software Development and Delivery Makes the Vision of DevOps a Reality

Agile Management Blog - VersionOne - Mon, 11/23/2015 - 18:58
2 Barriers to Unifying Dev and Ops

What are the two barriers to unifying Development and Operations?

Are you finding that DevOps is more vision than reality? Here’s how you can unify the systems that DevOps workflows depend upon to help make your DevOps vision a reality.

DevOps Can Be More Vision Than Reality

The DevOps movement has provided organizations building software with a vision of increased deployment frequency, product quality and mean time to recovery gained from improved collaboration and automation.

While propagating that vision has been a success, executing against it often remains challenging – especially in the enterprise. Ultimately the DevOps movement seeks to tightly unify Dev and Ops workflows, but so far two systemic barriers have kept these functions from becoming truly unified.

2 Barriers to Unifying Dev and Ops

I believe successfully unifying plan, develop, validate, deploy and run workflows is still challenging for two fundamental reasons:

  1. Plan and develop work items (features, fixes, stories, etc.) are not directly linked to operational outputs (builds, artifacts, environments, etc.)
  2. Lots of fragmented automation make it difficult to orchestrate and creates many pockets of siloed data.

1. Development Workitems Are Not Directly Linked to Operational Outputs









In any software delivery process, there is an inherent disconnect between development workitems and delivery outputs. The image above highlights a common pattern that organizations adopting DevOps face regardless of their level of DevOps maturity. This platform disconnect between functional workitems and delivery outputs makes it very difficult to truly unify development and operations.

Starting with the green box on the left, you have a simple representation of the agile development process. The main units of flow moving through the development organization’s storyboards have traditionally been workitems such as features, fixes, stories, epics, etc… However, once these development initiatives get converted into builds or artifacts and deployed into environments, the linkage gets muddy. At that point, “release” or “deployment” units of flow are only loosely affiliated with their corresponding workitems back in the agile storyboard on the left.

Feature attributes such as cycle time and current status can be tracked accurately while moving within context of the development storyboard, but manual updates to that data are required during downstream delivery. This creates a very weak understanding of the real-time flow of value once you get beyond the planning tool and into the downstream and more “operational” software delivery process.

According to a recent DevOps Survey conducted by VersionOne, more than 85 percent of respondents indicated that multiple systems are required to manually cross-reference features and fixes with their corresponding builds, artifacts and environments. This problem then gets magnified as functional changes “queue up” in later stage environments between release events. This lack of automated manifest reporting makes it increasingly difficult to express with certainty which workitems are included within specific artifacts and deployed into specific environments at any given point in time.

Here are a few questions that are typically difficult to answer with absolute certainty:






It will continue to be difficult for all stakeholders across the end-to-end delivery pipeline to collaborate at the highest level if Dev and Ops platforms are not truly unified. Building DevOps maturity mandates a tight linkage between functional workitems and corresponding delivery outputs to streamline the flow of value and simplify cross functional collaboration.

2. Automation Processes and Tools Are Fragmented










A clear and positive outcome of the DevOps movement is the emergence of a plethora of point process automation tools. These tools have been important enablers of DevOps practices and have dramatically reduced the amount of time required to validate, deliver and manage new software. However, the primary data models of these DevOps automation tools are wholly unaware of concepts such as features and fixes. Since these workitems represent the actual “content” flowing thru automation, visibility and traceability at the feature/fix level is critical to driving efficiency in a DevOps setting.

The image above depicts the fragmented delivery environment that frustrates our ability to link delivery outputs with functional workitems. This graphic was shared with me recently by an organization trying to enhance their ability to track the flow of value, in real-time, thru their delivery pipelines. If DevOps is a priority at your organization, this example is probably similar to what you have now or what you will have in the not too distant future.

As this very busy diagram indicates, the DevOps automation tools we depend upon to move value from the initial commit all the way out to production are continuously generating important audit, test and deployment data at every stop across the delivery pipelines. However, this data is often under-leveraged and buried deep inside tools completely unaware of the features and fixes flowing thru them.

Because of this fragmentation and lack of context, it is very difficult to provide critical status and audit data back to DevOps stakeholders. Without a unified development and delivery platform, correlating data generated through delivery pipelines back to specific features and fixes will continue to be a largely manual, error prone and time-consuming process.

4 Costs of Dev and Ops Not Sharing a Unified Platform

The costs of development and delivery not being unified is a missed opportunity. While small and incremental gains toward end-to-end unification have yielded progress, the reality is that most enterprise software development organizations are still struggling to improve:

value-stream1. Value Stream Efficiency

Because of the units of flow problem, stakeholders don’t have automated visibility into the status or and/or deployed location of the features and fixes flowing thru a delivery pipeline. As a result, manual effort is required to perform continuous business-to-operational cross-reference reporting and analysis that introduces material and unnecessary overhead into the software delivery value stream.

continuous-improvement2. Opportunities for Continuous Improvement

The plethora of fragmented point automation generates siloed data that is difficult to access and correlate back to a discrete set of features and fixes without significant human intervention. This fragmentation makes it difficult to collect meaningful statistics that can identify bottlenecks across the entire software delivery chain. This data is the crucial fuel required to drive the kind of continuous process improvements needed to materially increase delivery frequency and shorten time to market.

software-quality3. Software Quality & Failure Rate of New Releases

The lack of end-to-end visibility into the entire value stream makes it difficult to know with absolute precision which functional changes have been included in any given build or artifact. This reconciliation process is almost always manual and is susceptible to errors that increase the odds of deploying unstable or incomplete “work-in-progress” into critical environments.

meantime-recovery4. Mean Time to Recovery & Slower Analysis

The lack of detailed end-to-end delivery accounting and audit history, at the business level, frustrates the ability to find root cause and issue repairs for issues and defects once uncovered. Additionally, this un-correlated data makes it difficult to perform the detailed analysis needed to identify system or process failures that caused the introduction of critical production defects in the first place.

What Is a Unified Software Delivery Platform?








In order to make the vision of DevOps a reality, a truly unified platform that supports the end-to-end delivery stream – from idea to production is a primary requirement.  A crucial capability to achieve platform unification is the ability to link together all of the data generated throughout the delivery process. If data can be gathered and correlated at the time of creation, a comprehensive dashboard can be created that supports real-time collaboration across stakeholders.

Most organizations that have multiple agile teams are already using some sort of agile lifecycle management platform to manage priorities and coordinate development activities. By reimagining our storyboards as development, validation, and deployment orchestration hubs, we can unify the planning and development platforms with the infrastructure required to support downstream automation – without ripping out or replacing any of the tools and technology you’ve already implemented.

By leveraging centralized pipeline orchestration, you can better track work items as they move from one stage to the next in your storyboard. Because the orchestration layer understands automation in context of the features and fixes flowing thru it, stories can now be directly associated with the artifacts, builds, config files or deployments, linking these two traditionally decoupled platforms.

When your storyboard is linked with all the DevOps automation tools that move changes from the first commit all the way out to production you can begin to capture and associate the important audit, test and deployment data generated at each and every point within your delivery pipelines.This is the type of unified software delivery platform that can help make the vision of DevOps a reality.







Here are a few characteristics of a Unified Software Development and Delivery Platform:

  • Unified DevOps repository that can support robust cross-referencing between business value (features/fixes) and operational objects (builds, artifacts, deployments).
  • Ability to visualize, measure and optimize the journey of features and fixes from idea all the way to production deployment.
  • Robust pipeline orchestration that leverages existing DevOps automation and eliminates or minimizes the need for manual handoffs.

The 5 Benefits of Unified Software Development and Delivery

increased-collaboration1. Increased Collaboration Across All Disciplines

Product Owners, Project Managers, Developers, Testers, and Ops team members can more easily collaborate because business work items are linked to delivery outputs providing visibility, traceability and clarity across the entire value stream.

increased-automation2. Increased Automation and Streamlined Value Streams

The plethora of fragmented point DevOps automation tools are now orchestrated by the unified DevOps orchestration engine, reducing the need for human intervention.

increased-deployment3. Increased Deployment Frequency & Shorter Time to Market

With clear visibility of the entire value stream it is much easier to make the continuous process improvements that can increase delivery frequency and time to market.

improve-software4. Improved Software Quality & Reduce Failure Rate for New Releases

The ability to automatically cross-reference any build or binary to the features and fixes included within – with absolute precision – greatly reduces the chances of testing in the wrong environment, accidently promoting works in progress or items with unmet dependencies. This capability results in higher release quality with less wasted manual effort.

shorter-meantime5. Shorter Mean Time to Recovery & Faster Analysis

Unified audit and traceability throughout the entire software delivery process – from idea to production – will make it much easier to uncover issues prior to deployment. When defects do reach end-users, post-mortem root cause analysis can occur in minutes instead of weeks, uncovering root cause and prevent issues from recurring.


The independent evolution of planning platforms, build automation, testing and release management tools has created a profound and systematic data division between Dev planning platforms and Ops automation. As long as these disconnects persist, achieving the key DevOps ideal of cross functional collaboration and streamlined process flow is challenged.

Unified Software Development and Delivery is the process of merging these two universes to provide a comprehensive and end-to-end value stream that documents the flow of business value from idea to production. The VersionOne® Continuum™ for DevOps solution is one example this type of platform.  For more information, visit

The post How Unified Software Development and Delivery Makes the Vision of DevOps a Reality appeared first on The Agile Management Blog.

Categories: Companies

Creating Great Teams

Scrum Expert - Mon, 11/23/2015 - 16:20
Based on their experience with Trade Me, New Zealand’s largest e-commerce company, Sandy Mamoli and David Mole have written a complete guide on why and how you could implement a self-selection process for your teams. If you believe in self-organization for Agile project management teams, you should also think about self-selection. The “Creating Great Teams” book provides a complete overview of the self-selection, from its definition ...
Categories: Communities

Conferencia Agile Spain, Madrid, Spain, December 3-4 2015

Scrum Expert - Mon, 11/23/2015 - 15:53
The Conferencia Agile Spain is the main Agile event for the Agile community of Spain. This two-day conference brings together local and international Agile and Scrum experts for an exceptional learning, sharing and networking experience with presentations and workshops. In the agenda of Conferencia Agile Spain you can find topics like Scrum, Kanban, highly productive teams, retrospectives, planning, efficient meetings, team phases motivation, conflict management, team ...
Categories: Communities

Real-life Agile Scaling – slides from keynote @ Agile Tour Bangkok

Henrik Kniberg's blog - Mon, 11/23/2015 - 07:00

Here are the slides from my keynote “Real-life agile scaling” at Agile Tour Bangkok. Enjoyed hanging out with everyone!

Key points:

  • Scaling hurts. Keep things as small as possible.
  • Agile is a means, not a goal. Don’t go Agile Jihad. Don’t dump old practices that work.
  • There is no “right” or “wrong” way. Just tradeoffs.
  • There is no one-size-fits-all. But plenty of good practices.
  • Build feedback loops at all levels. Gives you better products and a self-improving organization.

Here is an InfoQ article with a nice summary of the keynote.

Sample slides:

Henrik Kniberg

Good vs Bad dependencies

Stuff to figure out with multiple teams

Scaling Chaos

Conflicting goals - full-stack teams vs small teams

Alternative to MVP



Categories: Blogs

Knowledge Sharing

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