Skip to content

Feed aggregator

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

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

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

The 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

Overcome the 6 Traps of an Agile Transformation

DFW Scrum User Group - Fri, 11/20/2015 - 16:48
We were fortunate to have David Hawks of Agile Velocity speak at our Dallas October meeting–it was a great session! Accelerating learning is the key to unlocking the true potential of Agile, and David shared the 6 traps agile teams fall into … Continue reading →
Categories: Communities

How Scrum Created the Greatest Team in the World

Rally Agile Blog - Thu, 11/19/2015 - 18:58

The Scrum approach to delivery has produced the greatest team in the world. And the elements behind the team’s success are repeatable, meaning your team could be next in becoming the greatest team in the world. (That sure has a nice ring to it.)


View image |


The team I’m talking about is the All Blacks, which retained its Rugby World Cup crown recently—the first team to do so since the tournament started almost 30 years ago. In case you’re not familiar with the All Blacks, in the past four years the team has only lost three of its 54 matches and the last time it lost consecutive games was in 2011. In fact, the All Blacks hasn’t lost on its home turf since 1994, before some of its current players were born. Yet their captain is from tiny Kurow, New Zealand (population 339), the coach is a former policeman and none of the players has the letters MBA after their names or got on the team through family connections. The team also comes from a country with a much smaller population and lower GDP than its next few rivals, so they’re not the biggest or the richest.

How does a country with more sheep than people produce a team recognized as the world’s greatest, and what does this have to do with Scrum?

Indeed, why are we referencing a sports team when most of us work in teams in urban offices where we chase paper and deadlines rather than an oval-shaped ball? Because high-performing teams, no matter what their domain, share many commonalities. And it’s a happy coincidence that the All Blacks practice the sport that gave the Scrum approach to product delivery its name.  (Very briefly: for those who have just joined us, two Japanese researchers of high-performing teams in 1980s workplaces came up with the term “Scrum” as a good fit for the characteristics associated with high performance, including speed, flexibility and handling uncertainty.)  

Let’s examine a few of the characteristics of the greatest team in the world to better understand how our own teams can become ultra high-performing. Given that rugby in New Zealand/Aotearoa is our metaphor here for high performance, I’ll be introducing a few new words into your vocabulary.

Principle 1:  Be Your Role

People on high-performing teams know their roles inside-out. Knowing your role doesn’t just relate to the bullet points in your job description: It means intrinsically knowing how your skills influence your teammates and how you collectively use these skills to succeed.


View image |


For All Blacks captain Richie McCaw, who has an impressive win rate of around 90 percent from his 140 caps, this meant sitting down with his uncle when he was a teenager and identifying on a scrap of paper what he needed to do to become a “G.A.B.”—a Great All Black—then taping it to his bathroom mirror so he could see it every day. In other words, visual management. Sound familiar?  

On your team, what’s the difference between a developer and a great developer, or a product owner and a great product owner? What about for your own role? These probably aren't characteristics that were bulleted in your job description.

Knowing your role means sticking to the basics, even when things are difficult, and trusting your team to do the same. For example, if you’re leading 8–7 in a tense final against your bogey team (France) you should focus on solidly executing the fundamentals, again and again. Nothing fancy, just K.I.S.S. This is where your 10,000 hours of purposeful practice pays off. Several past and present All Blacks sprint fast enough to compete in the early rounds of the Olympics 100 meters event. They’ve completed years of purposeful practice in order to deliver effectively under pressure.  Keep executing the drills you have practiced in training. Don’t skip your planning sessions or retrospectives because “you’re too busy” or “there’s a deadline.”

Once you know your role, the next step is to elevate it, redefine it and be your role. For example, number 10 for the All Blacks, Dan Carter, has arguably redefined the role of first-five eighth (relax, that’s as technical as we’ll get with rugby). In Japanese martial arts, this aligns to the concept of shu-ha-ri. While many of his contemporaries are content to score points through kicking, Carter is sufficiently cross-functional to play well outside his role and carry the ball across the line, rather than pass it to another player. Given that several players oin the All Blacks are similarly cross-functional, that makes for a powerful advantage over mono-functional teams.

Principle 2:  Be Cross-functional

Fundamental to Scrum is the cross-functional team, which means there are multiple paths for work to reach the “done” state. This complements, rather than contradicts, the principle of knowing your role. On a rugby team there are 15 players, each with a specific role. However, a player’s role is superseded by the team’s overall goal of delivering the ball across the try line (or goal posts). This means that a player like Dan Carter, whose primary role is to score points through kicking, has also scored 29 tries (similar to a touchdown) in international rugby because he is T-shaped. Unlike many of his rivals, his jersey is just as dirty at the end of the game as the rest of the team.


View image |


When we talk about “T-shaped people” in agile it means people whose deep technical knowledge is complemented by a breadth of skills. This counters situations where a person becomes a single point of failure or a bottleneck, as is so well demonstrated in the agile cult classic book, The Phoenix Project. Teams in the workplace can incrementally increase their cross-functionality over time by creating a simple skills matrix and allocating a few hours per week to upskilling. After three to six months, the team will be quantifiably stronger and have reduced its dependence on a single individual.

As a team member your versatility makes you more valuable to the organization, and that’s something to bear in mind for challenging times.

Cross-functionality goes hand in hand with diversity and high performance. The All Blacks are arguably the most diverse team at the Rugby World Cup, and it’s no accident that in recent decades, as the team has embraced more diversity, it has won more games. Players come from several different cultural, religious and linguistic backgrounds. Harnessed to a strong vision (discussed in the next section), this diversity creates open-mindedness around trying new ideas and synergies that enable team members to be authentic and bring their whole selves to the team.

Research confirms that team diversity leads to increased creativity, better decisions and harder-working teams.

Your team may be more diverse than you realize. Many workplaces lose their human touch and it’s easy to get caught up in “doing” our work at the expense of building high-performing teams and getting to know the person behind the job title. A half-day investment in effective team-building activities a couple of times per year (which needn’t involve blindfolds, high wires or singing Kumbaya) will pay dividends, create “ba” and directly improve team performance.

Principle 3:  Be United Around a Vision

“We are the most dominant team in the history of the world.” Pretty audacious, huh? Perhaps not. The All Blacks created this vision before other teams started calling them “the world’s greatest team.” However audacious it is, it would be much harder to become the world’s most dominant team with a watered-down vision that exudes mediocrity, or with no vision at all. There’s no doubt about what this team wants to achieve.

So, back to our teams in the workplace: what’s your team’s vision?


View image |


We’ve already talked about being your role and being cross-functional. Perhaps it’s no surprise how well the All Blacks embody teamwork and uniting around a collective vision, given the strong influence of Maori and Polynesian cultures on the team.

As the cliche goes, “there is no 'I' in team.”

Just as Japanese culture embodies Lean principles, Maori and Polynesian cultures elevate the importance of the team (or family, collective or other group of people) over the importance of the individual. Western cultures, by contrast, often elevate the individual over the team (e.g. individual performance targets) which can lead to local optimization at the expense of the overall system’s performance. Focusing on team performance as the unit of success has a dramatic impact on how the team plays.  

Scrum and SAFe® require a sprint goal and product vision, respectively. Build on that in your workplace and establish a vision for your team. What are its values, goals and outcomes? This fosters a team that is united, focused and aligned, rather than a group of people who “happen” to work together.

Next Steps

Several All Blacks are expected to retire in the coming months. The good news is that there’s now an opportunity for another team to be the world’s greatest. Maybe it will be a team in your organization. How can you elevate your team’s performance so it exhibits the same traits as the world’s greatest team?

  1. Help your team move from doing their role to being their role
  2. Make cross-functionality and T-shaped team members the norm through purposeful practice
  3. Create a compelling vision with your team that encourages high performance

There’s a Maori phrase that concisely sums up these themes:

Ko ahau te kapa, ko te kapa ahau – I am the team and the team is me." Suzanne Nottage
Categories: Companies

How Long Are Your Iterations? Part 1

Johanna Rothman - Thu, 11/19/2015 - 17:08

I spoke with a Scrum Master the other day. He was concerned that the team didn’t finish their work in one 2-week iteration. He was thinking of making the iterations three weeks.

I asked what happened in each iteration. Who wrote the stories and when, when did the developers finish what, and when did the testers finish what? Who (automated tests, testers or customers) reported defects post-iteration?

He is the Scrum Master for three teams, each of whom has a different problem. (The fact that he SMs for more than one team is a problem I’ll address later.)

Team 1 has 6 developers and 2 testers. The Product Owner is remote. The PO generates stories for the team in advance of the iteration. The PO explains the stories in the Sprint Planning meeting. They schedule the planning meeting for 2 hours, and they almost always need 3 hours.

Staggered_dev_testingThe developers and testers work in a staggered iteration. Because the developers finish their work in the first two-week iteration, they call their iterations two weeks. Even though the testers start their testing in that iteration, the testers don’t finish.

I explained that this iteration duration was at least three weeks. I asked if the testers ever got behind in their testing.

“Oh, yes,” he replied. “They almost always get behind. These days, it takes them almost two weeks to catch up to the developers.”

I explained that the duration that includes development and testing is the duration that counts. Not the first two weeks, but the total time it takes from the start of development to the end of testing.

“Oooh.” He hadn’t realized that.

He also had not realized that they are taking too much work (here, work in progress, WIP). The fact that they need more time to discuss stories in their planning meeting? A lot of WIP. The fact that the developers finish first? That creates WIP for the testers.

Sequential work makes your iterations longer. What would it take for you to work as a team on stories and reduce the lag time between the time the development is done and the testing is done?

The next post will be about when you have a longer duration based on interdependencies.

Categories: Blogs

Impressions from Gartner Symposium/ITxpo

TargetProcess - Edge of Chaos Blog - Thu, 11/19/2015 - 15:55

Last week I attended Gartner IT Symposium in Barcelona. My interest was to check what is on the agenda of CIOs these days as well as to look closer at what Gartner is saying about the Project Portfolio Management Market. Over 2000 CIOs from Europe flew to Barcelona this year, around 45% from companies with 20k+ employees, the majority from Financial or Government sectors, UK and Scandinavia.


Here I’ll share some findings, mostly related to the topic of Project Portfolio Management, as this was my focus there.

Where CIOs spend IT budgets

Among all CIO’s priorities, the top list this year looks like this:

  1. BI
  2. Infra/Datacenter
  3. Cloud
  4. ERP

Overall, the digitalisation of businesses happens rapidly, 60% of all services are expected to digitalise in the next 2-3 years.

One buzzword which I heard almost every half an hour was


Simply put, bi-modal means that there are two modes of operation: mode 1 – stable, where priorities are on productivity, safety and optimised cost, and mode 2 – experimental, where the focus is on innovation and agility. The message here is: don’t just operate your IT, innovate and be agile too. Almost in every session I attended Gartner analysts mentioned this buzzword. The threatening message to CIOs was that if they don’t innovate there will be disruptive newcomers from even outside their known market segment who may leave them without jobs.


Agile was mentioned quite often, Gartner stated that 76% of companies do Agile these days and this certainly sounded as the way to go. Other practices mentioned from Mode 2 were Multi-Disciplinary Teams, Crowdsourcing, Different Metrics (operation, innovation, guardian), and working with Startups.

Agility in application context was also a big topic. The key recommendation was: reduce your application complexity (Application Agility = 1/Complexity). IT organisations should:

  • benchmark the current complexity of applications (there are tools that evaluate code complexity, etc.)
  • set goals for reducing the complexity
  • measure and refactor or replace complex applications

The agile methodology should be used to deliver value faster and should not be regarded just as an effective way to expedite the development processes. Here is a convincing slide about the direct results from agile delivery focused on speed only:


Talent Management

This fancy term stands for HR, although I certainly like that we talk about talent and not resource. Apart from the necessity of becoming good leaders and creating a proper company culture, getting it right with Talent Management is critical because people are the main asset of any company.

So here Gartner was telling CIOs to “let people work on what they want” and “help them develop their skills”.

This reminded me of an interesting case I heard recently from Jens Korte, an agile coach I had a chance to work with lately. Jens is well versed in both Talent Management and Project Portfolio Management. He consulted a customer who wanted to have a clear and visual way to manage talent in their company. The line of thought is the following:

what jobs do we want to get done? > what skills do we need for that? > which skills do we have? > where is the delta?

On the photo below you see a board where the horizontal lanes are people and the vertical lanes are different skills required for the best results of work. The red color of the post-it means this person has insufficient skills for a particular job, and green means s(h)e is great in it. A map like this helps to visualise some business capabilities which are currently underdeveloped in the team (e.g. in the 4th column from the left if Felix is sick – nobody can replace him for this kind of work).

That’s the physical version:


…or the digital version in Targetprocess (of course:)

Team Capabilities 2015-11-17 20-57-09

As a side note, I believe that helping modern companies to do Talent Management/Development is a promising area for a visual management tool like Targetprocess and we shall definitely be looking more into this soon.

PPM: Link between Strategy and Execution

I attended a session by one of PPM analysts at Gartner – Lars Mieritz – to the subject of Business Outcomes in a Project Portfolio.

The message was rather simple: there is a gap between the goals of a company’s senior management and the execution of the projects. And we need to close this gap by making business benefits more meaningful in the pre-project stage through a set of business outcome performance indicators and metrics that tie back to the business case and its stated benefits.

Example: CEO and the Board of Directors have a business initiative like “increase client satisfaction with our customer service in 2016”. This generates a portfolio of projects e.g. trainings for customer service teams, replacement of the old CRM with a more modern one, etc. Problem: when PMO plans this portfolio it is hard for them to understand which projects are more important than the others (they cannot do all of them due to limited resources) and how to see if projects were successful. As a result, they would often just evaluate the projects by the Cost/Benefit ratio and those projects which have the highest ratio are considered to be successful. But this is not always true.

Solution: CEO/Executive Board define Critical Success Factors (CSF) and  metrics to measure those business outcomes. E.g. CSF = 30% increase in satisfaction rate with  Customer Service and the metric = a customer survey in the beginning and the end of the year should benchmark the current and new satisfaction rates. Practically, this happens by providing a Business Case document for each objective which has a bunch of parameters. The Business Case document needs to be filled in by the business executives who should indicate expected outcomes and the metrics for measuring the project success.

PMO would then be able to clearly define their project portfolio based on these expected outcomes and related metrics. To summarize it, the correct sequence should be as follows:

  1. Business objectives are defined with Critical Success Factors (CSF)
  2. Business benefits are formulated
  3. Required business changes are defined along with the metrics (they should be directly related to the original business objective vs. being purely technical such as e.g. server availability %)
  4. The defined business changes are enabled
  5. Project portfolio is managed by the CSF and metrics


Another topical problem for many companies nowadays seems to be the necessity to enable fast feedback in both directions:

BUSINESS > IT (e.g. “guys, don’t do this project anymore, the priorities changed last month”)

IT>BUSINESS (e.g. “this project is stuck or this has been already delivered, try this out”)

Gartner recommends to have an agile feedback mechanism between Business and IT, which means to exchange information faster and more often.

(Side thought: Targetprocess customers could solve these problems by

  1. a) Letting company’s executives create initiatives and specify their expected outcomes and metrics as part of the initiative’s attributes
  2. b) PMO/IT Dept quickly feed back the status of projects and are updated on the changes in strategy

Our product specialists can help you set up Targetprocess that way.)

PPM Hype Cycle

Another PPM presentation I attended was called “PPM Hype Cycle” by Teresa Jones. A hype cycle is something that could be easily described with an analogy with a couple’s relationship. In the beginning there is a lot of excitement then a lot of disappointment and later (if the couple did not get divorced in the greyest days) the line goes up again, and this is called a “mature relationship” then:)

It looks like this:


So now here’s what Gartner says about the hype cycle of the Project Portfolio Management market. I will go through different stages of its development, I marked the most important ones with numbers on the graph above. I didn’t catch all items so I will mostly highlight here those that I think are especially interesting:

1)… (not sure what it was)

2) adaptive Enterprise

3) Business Transformation office

4) Hybrid of Cloud and On-Premise application management skill set

5) Project Collaboration space (=online tool for project management)

6) Adaptive Program Management

7) Collaborative Work Management (knowledge work, not just projects)

8) Integrated IT Portfolio Analysis (this means an alignment of applications, projects and services in the same portfolio)

9) NPD = New Product Development Portfolio (here the Gartner analyst pointed out that this space is new and there are no good tools covering this yet, it is still a niche to be filled and new tools сan be expected in this space soon).

10) Agile project management

11) Kanban for programs

12) Application Portfolio Management (the challenge here is to monitor the status of applications in real-time)

13) Cloud-based PPM tools (here Gartner said that the new cloud-based tools are good at Project Management and not yet good enough at Portfolio management)

14) PPM Certification

15) Reporting Enterprise PMO

16) Resource Management. Gartner’s point here was that current implementation of Resource Management in PPM tools is too detailed, too complex, needs to be done differently: rather high-level capacity management is needed than too detailed person-level management)

17) IT PMO

18) Earned Value management

19) IT PPM applications. They said here that old PPM tools are hard to update and a new generation of PPM tools should come around

20) PPM for Professional Services

21) Idea Management (they thought that this area may soon move into another market segment).

An interesting thing is that Integrated PPM, NPD, Agile and Kanban are on top of this hype wave and these are the areas where agile tools like Targetprocess are surely most familiar with and powerful at.

I had a chat with Teresa after her session and introduced Targetprocess quickly (she didn’t know of it, of course). We didn’t go into many details but to my question about Capacity Management, she said that current PPM vendors may be doing too much there and 80% of this functionality should be more than enough. Also she said that planning and managing people resources too granularly and too in advance could be a big mistake and her suggestion is that there should be a 2-step process:

Step 1: High-level capacity planning. We ask ourselves “Can we do this project next summer?” And if the answer is most probably YES, we put it on the roadmap

Step 2: When it comes closer to the implementation of the project, we plan it in more detail (which skills do we need, do we have people with the required skillset available? Days off and public holidays?)

Capacity Management is a topic we are working on full speed right now and it would be indeed interesting to collect more feedback from any of you reading this post and involved with Project Portfolio planning and capacity management in your companies. How long in advance is capacity and resource planning relevant for your business, do you plan on the personal or less granular (team? squad?) levels? Please feel free to post in the comments here or contact us directly by mail info(@) if you want to share your ideas.

Categories: Companies

Targetprocess v.3.7.12: minor bug fixing

TargetProcess - Edge of Chaos Blog - Thu, 11/19/2015 - 15:03
Fixed Bugs
  • Customize cards: “Progress” unit shows 0% for completed work if it’s estimated at 0 points/hours
  • Fixed: Failed drag-n-drop of a card with custom fields if drop-down custom fields are lanes
  • Fixed: Team iteration split error “[UserStory.Effort]: Effort should be equal or greater than zero.”
  • Fixed: Custom Rule ‘Assign Task to a person who started it’
  • Fixed: Loss of custom field values on a card moved within a multi-select custom field lane
  • Fixed: Avatars of Targetprocess users are not shown in the ‘Owner’ field list on a Request view
  • Improved performance when expanding hierarchical lists


Categories: Companies

ACE! Conference 2016 Call for Speakers

Scrum Expert - Thu, 11/19/2015 - 10:57
The ACE! (Agile Central Europe) conference is the largest event about Agile project management and software development in Central Europe, attracting people from all over the region. It will take place in Krakow, Poland on 14-15 April 2016. The ACE! 2016 conference combines lean/agile and LeanUX/Lean Startup topics in two tracks of 45 minute talks and adds a workshop track for workshops of 1-2 hours in ...
Categories: Communities

When Do You Need a DevOps Team?

Leading Agile - Wed, 11/18/2015 - 18:41


With all the focus on continuous delivery and test automation, the inevitable question arises, “do I need a DevOps team?”. Just as with other Domain type teams that support software delivery teams, looking at the general question, “should I form a Domain team?” will help answer our DevOps question. So let’s back up.

What is a Domain Team?

A domain team is a cross-functional software delivery team with a special skill set. This skill set is needed by some or all of the delivery teams in an organization.  An example of a special skill set is ETL Developers. Where the database structure and queries can be developed within a delivery team, the data loading and associated file maintenance is a small portion of the entire functionality. To bring in an ETL specialist for one or two sprints and then send them off again defeats the purpose of keeping the team together.

Collecting the ETL new development work with the ETL maintenance work into a single backlog presents the opportunity to staff an ETL team that can support multiple delivery teams.  Now here is the tough question in Agile Software delivery terms. Is this an Agile team? They have a defined backlog of work. They are cross-functional if we include a Business Analyst to help with story analysis and Quality Analyst to help with testing. What they may not have is a product or project and probably not a release as thought of in the Java world. The kicker is whether or not they would have a product owner. In most cases they will not have a product owner or a product team, but will need to gather stories from other teams.

Justifying the Need for a Domain Team

The answer to the question, how do I know if I need a domain team, is to collect the numbers. Is the capacity of the delivery team impacted by the need to “occasionally” perform with specialty skills? Do we have a quality issue with the work completed? Are there other teams that need this skill set? Will there be a maintenance load that will need this skill set?

Answering these questions and collecting data will not only help to define the size of the team needed but will provide numbers for the justification of the team. We all underestimate the cost in productivity of context switching. Having members of the team stop functional delivery for operational maintenance or to use a special tool can drag down the entire team. Use velocity variance, escaped defects and hangover points to build the case for having a specialty team. Collect the same data from other teams to strengthen your case.

How Do I Know if I Need a DevOps Team?

First define the work of the team. The team could be responsible for only building and deploying software in different environments. It could be responsible for building metrics, analyzing regression suite failures, running security and performance test.

Once you draw the line on the responsibilities collect your data.  If your team in combination with other teams in the organization are spending more than one person’s effort on these activities every sprint make the business case for creating the team.

Create the policies for this team to accept work. These policies and their work-flow must be explicit. Without clear guidance the other delivery teams may see your new DevOps team as an opportunity to move all tasks remotely related to the DevOps team.  Defining how the software will be deployed and writing the deployment scripts still lies with the delivery teams. Making sure the deployments are fast, accurate and report results are the responsibilities of the DevOps teams.
DevOps cartoon

Finally, expect some hiccups along the way. Whenever new teams and new processes are introduced there will be the need for education as well as trial and error. Make sure you have strategies that allow for some mistakes. Whether it is training, communication plans, user guides or on-boarding practices, everyone needs to know what the new team does and how to work with them.

You need a DevOps team if you can justify the need with data, define the responsibilities, and define a strategy for communicating who is in the team and what the new processes are.

The post When Do You Need a DevOps Team? appeared first on LeadingAgile.

Categories: Blogs

New Blog Entry at

NetObjectives - Wed, 11/18/2015 - 15:55
We've got another new entry over at: ...which is all about the way unit tests can be structured to make them better specifications. We welcome comments at the Sustainable Test-Driven Development blog site. Thanks!

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Clarizen Fall Release Enhances JIRA Integration

Scrum Expert - Tue, 11/17/2015 - 18:08
Clarizen has announced its Fall 2015 Product Release, delivering dynamic new options for viewing work, as well as a stronger integration between Atlassian JIRA and Clarizen. The enhanced JIRA integration allows JIRA users’ work to be reflected and managed in Clarizen, providing full content creation and collaboration capabilities. The JIRA v2 integration strengthens everyone’s work connections and align teams with an enterprise-grade bidirectional integration. When one ...
Categories: Communities

Free Retrospective Tools for Distributed Scrum Teams

Scrum Expert - Tue, 11/17/2015 - 17:06
Even if Agile approaches favor collocated teams, distributed Scrum teams are more common that what we might think. Many Agile software development teams are based on a virtual organization. This article presents some free online tools that can be used to facilitate retrospectives for distributed Scrum teams. You will find in this article only tools that are supposed to be used for free in the long ...
Categories: Communities

Leave Work Unassigned and See Who Steps Forward

Create vacuums and then see who steps in to fill them

Early in my career, I noticed the project managers in my company drove nicer cars than we programmers did. (This was back before companies had learned to fully value their technical staff.) After a few years of noticing those nicer cars, I asked my boss what I needed to do to become a project manager. He told me, "When you start acting like a manager, I'll make you a manager."

This advice wasn't unique to him. I've since heard it from many other bosses. And it's actually not bad advice.

The problem with my boss's advice was that there were no opportunities for me to start acting like a manager. Each of the company's projects already had a project manager assigned to it. If I had started acting like the manager of a project that already had a manager, the officially appointed manager would have been quite annoyed with me.

If my boss had really wanted me to start acting like a manager in order for him to promote me into that role, he should have left a void in the organization for me to fill. In fact, an important part of a leader's job in an agile organization is to create vacuums so that the right people can step forward and fill them.

Creating a vacuum entails deliberately leaving a gap in an organization. Rather than filling the gap by identifying a specific person or group of people to fill it, a leader can point out the gap, and then see what happens. The benefit of this approach is that it allows people to work in areas where they are passionate.

As an example, many years ago, I was working as a VP of software development. Some of the first XP teams in that company discovered the benefits of continuous integration, and I was excited to spread this practice across the department. I could have appointed someone to make that happen.

Instead, at the next department meeting, I talked about how impressed I was with what those teams had done, and how it was going to be important for us to spread that good practice to other teams. Without explicitly saying so, I let it be known that this was something people could work on.

Of course, for this to work, leaders also need to create a culture in which employees do not have every waking moment of every day committed to project work. Companies don't need to go so far as the well-known Google 20 percent time, but employees should generally have some time they devote to work of their own choosing.

This is a sign that leaders trust employees. It is also a recognition that it is impossible for a leader or manager to identify the highest priority work in all cases.

If you're a leader in an agile organization, the next time you need something done, rather than assigning someone to the work, consider creating a vacuum and seeing who steps into it.

Categories: Blogs

Javascript Goes Back to Class

Not long ago at a user group I saw a strange piece of sample code like this on an overhead projector:

class Person {

  constructor(firstName, lastName) {
    this.firstName = firstName;
    this.lastName = lastName;

  fullName() {
    return this.firstName + ' ' + this.lastName;


I chuckle a little bit inside. I’ve heard plenty of arguments over the years that Javascript’s prototypical inheritance was the right way to do things and trying to force traditional OO on Javascript was doing it all wrong:

If you’re creating constructor functions and inheriting from them, you haven’t learned JavaScript. It doesn’t matter if you’ve been doing it since 1995. You’re failing to take advantage of JavaScript’s most powerful capabilities. — Eric Elliot

It turns out ECMAScript 6 has officially added class style OO to the language. So the needs of many occasional Javascript developers to have a more familiar looking construct that would be at home in Java, C#, or Ruby eventually won.

Categories: Blogs

How team diversity enables continuous improvement

Ben Linders - Mon, 11/16/2015 - 23:57
Continuous improvement requires that people reflect and find ways to do their work in a better way. Having diversity in agile teams makes it possible to discover and explore new ways of working, where uniform teams with identical kinds of people would aim for steadiness and don't want things to change. Let's explore how you diversity can enable continuous improvement using agile retrospectives. Continue reading →
Categories: Blogs

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.