Skip to content

Feed aggregator

Measuring DevOps Performance Using a Value-Based Approach

The Agile Management Blog - VersionOne - Tue, 10/18/2016 - 14:30

Are you measuring the value, risk, and quality flowing through your DevOps pipelines? Here is a value-based approach to measuring DevOps performance that will help your organization better evaluate the effectiveness of its DevOps initiatives. As organizations become increasingly value-stream … Continue reading →

The post Measuring DevOps Performance Using a Value-Based Approach appeared first on The Agile Management Blog.

Categories: Companies

GitKraken v1.8

About SCRUM - Hamid Shojaee Axosoft - Mon, 10/17/2016 - 21:33

Are there any Guns N’ Roses fans in the house? Anyone? You over there in the corner—yeah you, what was the name of the amazing guitarist who wore a top hat and even though he wasn’t the lead singer, somehow managed to outshine Axl Rose?

Yes, it’s Slash! Good job!

slash keif

Why are we talking about Slash? Well, because our left panel keeps improving with every release and for v1.8, it’s all about the slash.

You’ll remember in our last release, v1.7, we made significant performance improvements to the left panel, which made life much better for everyone. Now, we’re introducing folders to the famed left panel.

Folder Hierarchy

If you have slashes in your branch, GitKraken will simply build a folder hierarchy for you.

GitKraken will be a folder hierarchy for you in the left panel.
GitKraken will build a folder hierarchy for you in the left panel.

News like this is so glorious, it’s just like hearing that sweet opening riff to Sweet Child O’ Mine. You should probably listen to it now just to remember how good it is. We’ll wait.


Okay, you’re back! And you’re already familiar with the fuzzy finder: another one of our helpful features that makes it easier and quicker to find things. Now, we’ve simply taken that functionality and applied it to the left panel as well.

You’ll notice that a new search box has been ever so delicately placed at the top of that left panel. So, you can use cmd or ctrl+ shift + F to find what you’re looking for. Suddenly you’re a rockstar…but with code, not a guitar!

Filtering has been added to the left panel. It's So Easy.

Filtering has been added to the left panel. It’s So Easy.

No more clicking, scrolling, cursing or wondering where your branches, remotes, pull requests, etc. are. Don’t Breakdown. Now you can simply filter with the search box. Oh, oh, oh, sweet love of mine!

Run on over to the release notes to read more. They won’t let you down like perhaps The Spaghetti Incident? did.

Categories: Companies

Real-Time Retrospectives & Agile Improvement

Scrum Expert - Mon, 10/17/2016 - 15:09
If the retrospectives are one of the main improvement tools for Agile teams, they can also be the subjects of improvement. In this article, Tom Monico explains how his team has adopted the starfish model to create a better retrospectives process where feedback is produced in real-time and not only at the end of a Scrum sprint. Author: Tom Monico, Many have embraced the retrospective while others, possibly most, have a more casual attitude towards the value of the retrospective. Personally, I was somewhere in the middle until my teammates and I developed a better way to learn from the past. We were performing very well. We routinely met our commitments and the business was happy. We held a retrospective at the end of each sprint going around the room asking each team member to share something that worked or didn’t work well. It was a very uncomfortable process for everyone. Since we were doing so well, we questioned the value of the retrospective and considered having the retrospective every other sprint, maybe even less often. Luckily, our desire to have the retro less frequently was short lived. We realized that even though we were doing well, we still needed to challenge ourselves to improve every sprint. If we didn’t, we wouldn’t grow as a team and we’d eventually become complacent about improvement. We needed something better. We needed a better retrospective. We wanted to make the retrospective as objective as possible so we adopted the starfish model using [...]
Categories: Communities

XP Days Germany, Hamburg, Germany, November 20-22 2016

Scrum Expert - Mon, 10/17/2016 - 08:30
XP Days Germany is a three-day conference focused on Agile software development. With its eXtreme programming background, it contains interesting technical best practices material for Scrum practitioners and Agile software developers. All the talks are in German. In the agenda of the XP Days Germany conference you can find topics like “Welcome to Dockerland: Best Practices for Kickstarters and Tools by Example”, “Lean Principles and the Management of Technical Debt”, “Test Driven DevOps”, “The 10 Golden Rules fur Bad Tests”, “Pair Programming – Developers Friend, Managers Enemy?”, “How Scrum Keeps Managers Happy – But Not Developers”, “Train your brain – Google Style”, “Continuous Database Integration with Flyway”, “Refactoring Legacy Code”, “Introducing Decombination”, “Design Sprints and Paper Prototyping”, “Lean Coffee”, “Test-Driven Layout – Implementation with Galen”, “The Journey towards Software Craftsmanship”, “Continuous Delivery. Lessons (Not) Learned”. Web site: Location for the XP Days Germany conference: Handwerkskammer Hamburg, Holstenwall 12, 20355 Hamburg, Germany
Categories: Communities

Agile Tour Paris, Paris, France, November 17 2016

Scrum Expert - Mon, 10/17/2016 - 08:00
Agile Tour Paris is a one-day conference focused on agile software development and Scrum that takes place in the capital of France. All the presentations and workshops of the Agile Tour Paris conference are in French. In the agenda the Agile Tour Paris conference, you can find presentations and workshops like “Agile Innovation with JTBD”, “The Art of Being Wrong”, “Coaching Agility in a complex world or what’s the difference between “pure” coaches and Agile coaches?”, “Building Trust inside a Team”, “User research game : learn how to validate your hypothesis!”, “Meeting Game”, “Scrum Clinic”, “Negotiating in Agile Projects”, “How to Achieve a Successful Intrapreneurship Experience in a Big Company”, “DevOps Killed Me”, ” LeanUX for Honest Product Owners”, “Agile Leadership”. Web site: Location for the Agile Tour Paris conference: Microsoft France, 41 Quai Président Roosevelt, 92130 Issy-les-Moulineaux, France
Categories: Communities

How we used to Scrum and XP to keep the conference on schedule

Scrum Breakfast - Sun, 10/16/2016 - 10:42
Last week, I attended and facilitated Scrum Day Portugal. This was one of the best conferences I have ever attended: Great talks, new information, great discussions off-line both with participants and speakers! And despite starting 15 minutes late, we finished on time. Everything just flowed! How did we do that?

It didn't start out that way. Scrum Day Portugal is a two day event. I arrived Tuesday afternoon, half way into the first day. The speakers were interesting, the talks were great, but we were running late. It felt like a death march project, even though the conference had barely begun.

My job was to facilitate the second day. We had a really tight schedule! Seven igniter talks followed by 2 Pecha Kuchas and 3 ½ hours of Open Space. I realized that staying on schedule would be both challenging and really important. If people are exhausted at the Open Space, they can employ the law of two feet (leave), and all the air goes out of the event. This would be a disaster. How to fix the problem?

Tuesday night, the speakers went out for dinner together. We talked about the problem. A big challenge was that most participants arrived late on Tuesday, and would probably do so again on Wednesday, so we could not just ignore our customers and start on time. Another challenge was that one speaker needed more time than originally planned. Not knowing how late we would have to start, we couldn't decide how to address the scheduling problem. We agreed to make the decision Wednesday morning.

On Wednesday, I invited all the speakers to a daily scrum, shortly before the opening was scheduled. While I tried to make a plan for the start times of each speaker, Chet Hendrickson started writing cards on the table. He made a card for each speaker, the coffee break and lunch.
Visualizing the program à la XP
At this point, I gave up on my “spreadsheet”! Using Chet's cards and the original schedule, we calculated the duration of each session. We agreed to start 15 minutes late, but keep the original timings. So we calculated the new start times for each speaker. What about the speaker, who needs more time? “I can shorten my talk, no problem!” said Manny Gonzales, CEO of the Scrum Alliance (when was the last time you heard a CEO volunteer to shorten their talk?).

What about transition times? There are no transition times, this is the time each of us starts. “Oh, so I have to shorten my talk a bit.” We all understood the problem and the goal. We had implicitly agreed to do our best to make it happen.

“The key word is responsibility,” explained Chet, “Everyone in the team has an obligation to do the right thing. The cards are a tool he uses in Extreme Programming to visualize system architecture, and thanks to the visualization, everyone knew what they had to do.

How did we stay on time? During the each session, I just needed to know who the next speaker was, when their session was scheduled to start. The speakers asked for a friendly wave at five minutes before the end of their session, so they could remain aware of when the had to finish.

In the worst case, a session ended in 1 whole minute late. Some of the speakers over-compensated (shortened), so by lunchtime, we were back on the original schedule!

So the conference ran smoothly and everybody left the conference with a smile. What does this have to do with Scrum and XP?
  • Someone was responsible for the process, and raised the questions. In Scrum, that person is called the Scrum Master.
  • The team got together to figure out how to achieve the day's goal. In Scrum that's called a Daily Scrum.  We left the meeting with a plan and a common goal.
  • The Scrum Master remained focused on the process, giving friendly reminders when it was helpful. 
  • The time-boxing gave us orientation and helped us deliver a great conference. 
  • Visualizing the problem and giving it to the whole team made solving the problem much easier. (I don't know what Chet calls his board, but it's a great approach.)

Categories: Blogs

Organisational Interstices

From Catherine Chang BlogEven if reinventing management voices say other way, it is still believed that dividing the work is more valuable than integrating it. management may treasure specialized departments,meventually externalized or centrally mutualized.
Nowadays though,  divide et impera is more and more recognised as a highly unadapted approach for the complex world of business. Agile thinking trend heavily agree with this. Nevertheless, we Agile supporters  may have a hard time to provide a clear explanation why is this so. A metaphor  (oh, thank you, Clean Language!)inspired by Karlene Roberts on HRO organisations  help to build some - hopefully helpful - arguments to describe the negative effect of siloted organisations.  Specialized silos, when they interact, create a "space in-between" that behave like "interstices" or "holes". Like in a raw material or fabric, these interstices are the main source of fragility. Organisational interstices behavior effectsLoss of knowledge when dividing the work by specialisationThe specialized, eventually externalized, organization has very sharp expertise, but ignores the synergy and the integrated knowledge of the whole operational chain.Conflicting interests The high cost of interstices One of the more or less recognised reasons  of creating specialized organisms is cost reduction. Usually the cost of this set-up is considerably higher because of interstices costs. When an interstices between two organizations happens, the need of "transve" communication and coordination rises quickly.  Therefore groups of coordinators, teams in charge of transversal communication and facilitators are created. The cost of the coordination can blow-up ceilings.
Enhanced fragility.  What does creating a transverse management and coordination group mean? More interstices, with all the related dysfunctions.! An infernal loop is created: interstices tend to self-multiply to fix their dysfunctions, therefore creating extra dysfunctions. Breaking the loop and and shift the associated mental model is the next challengeHow to close an interstices  The no punishment policy Inspired by the HRO ( High Reliable Organisatins) model. The practice  of  "immunity" in case of error is phased on the principle that learning and knowledge is acquired when there is no fear to tell all the facts that create the big picture of a post-incident. Silence is no value for learning, improving and avoiding further incidents....And punishment is the mother of silence.
Dear reader, does this seem an idealistic Disney world framework to you tight now? Then let me give you examples of organisations that apply the "non-punishment policies of HRO : flight companies, Air Force, and more and more hospitals and emergency units. So to say, very unexpected references of La-La  Wonderlands.
The non punishment policy leads to high reliability because big accidents can be avoided by open learning from minor incidents (near miss).
Categories: Blogs

How we (un)plan the future

TargetProcess - Edge of Chaos Blog - Fri, 10/14/2016 - 10:58

We have made some huge changes in our prioritization and planning process this year. In a nutshell, we have switched to open allocation. Here is the story.

Old way: boards, feature ranking, top-down approach

During the last several years we used to have a Product Board. This was a committee that focused on annual product plans. It consisted of up to a dozen people with various roles from sales to developers. We discussed our product strategy and set high-level goals (like "increase the market share at the enterprise market"). We created a ranking model that we used to prioritize features and create roadmaps:

Features ranking model

It kinda worked, but at some point I understood that somehow we pushed more and more features into Targetprocess, making it even more complex and heavy. Many people inside the company were not happy with this direction and they did not believe in it. Large customers demanded complex features like more flexible teams management, people allocation, an advanced QA area, etc. These are all good features, but we, as a company, somehow lost the feeling of end-user experience. Some simple things like search, navigation, performance, and simplicity were buried under fancy new features. This year, we put an end to that approach.

We want to create a tool that is pleasant to use. A tool that boosts your productivity and is almost invisible. A tool that saves your time. To achieve this goal, we have to go back to the basics. We should fix and polish what we have in Targetprocess already (and we have a lot) and then move forward with care to create new modules and explore new possibilities.

We have disbanded the Product Board, removed feature prioritization, done away with the top-down approach to people/team allocation, and replaced it with a few quite simple rules.

New way: Product Owner, Initiatives, and Sources

The Product Owner sets a very high level strategic theme for the next 1-2 years. Our current theme is very simple to grasp:

Focus on pains and misfits

Basically, we want to do anything that reduces complexity, simplifies basic scenarios like finding information, improves performance, and fixes your pain points in our product.

This does not mean that we will not add new features. For example, the current email notification mechanism is really outdated, so we are going to replace it and implement in-app notifications. But, most likely, we will not add new major modules into Targetprocess in the near future. Again, we are focusing on existing users and their complaints.


Our people have virtually full freedom to start an Initiative that relates to the strategic theme. An Initiative is a project that has start/end dates, a defined scope and a defined team. It can be as short as 2 weeks with a single person in the team or as large as 3 months with 6-8 people in a team.

There are just three simple rules:

  1. Any person can start an Initiative. The Initiative should be approved by the Product Owner and the Technical Owner (we plan to use this approval mechanism for some time in order to check how the new approach goes). The Initiative should have a deadline defined by the Team.
  2. Any person can join any Initiative.
  3. Any person can leave an Initiative at any time.
Sources and Helpers

A Source is the person who started the Initiative. He or she assembles the team, defines the main problem the Initiatives aims to solve, and is fully responsible for the Initiative's success. The Source can make all final functional decisions, technical decisions, etc. (Remember, Helpers are free to leave the Initiative at any time, so there is a mechanism to control poor leadership).

A Helper is a person who joins an Initiative and is committed to help complete it by the agreed deadline. He or she should focus on the Initiative and make it happen.

The Initiative deadline day is pretty significant. Two things should happen on the deadline day:

  • The Source makes a company-wide demo. They show the results to the whole company and explain what the team has accomplished.
  • The Initiative should be live on production.

As you see, freedom meets responsibility here. People are free to start Initiatives and work on almost anything, but they have to meet their deadlines and deliver the defined scope. This creates significant peer pressure, since you don't want to show bad results during the demo.

This process was started in July. We still have a few teams finalizing old features, but the majority of developers are working in the Initiatives mode now. Here's a screenshot of the Initiatives currently in progress:

Initiatives timeline

The Initiatives in the Backlog are just markers; some of them will not go into development, and there is no priority here. Next is the Initiatives Kanban Board:

Initiatives Kanban Board

You may ask, how do we define what is most important? The answer is: it does not matter. If we have a real pain from customers, and we have a few people that really want to solve this problem — it will be solved. Nobody can dictate a roadmap, nobody can set priorities, even the Product Owner. The Product Owner can start their own Initiatives (if they can get enough Helpers) or decline some Initiatives (if it takes tooooo long or doesn't fit the strategic theme).

As a result, we don't have roadmaps at all. We don't discuss priorities. And we can't provide answers to your questions like "when will you have a better Git integration". We can only make promises about things already started (you can see some of them above). All the people inside our company care about making our customers happy with the product, and now they have been enabled with real power to react faster and help you.

We can also promise that Targetprocess will become easier, faster, and more useful with every new release.

Categories: Companies

Coaches, Managers, Collaboration and Agile, Part 2

Johanna Rothman - Fri, 10/14/2016 - 02:19

In Coaches, Managers, Collaboration and Agile, Part 1, I wrote about circumstances under which a team might want a coach. It wasn’t an exhaustive list. It had several questions defining when coaches might help the team to become agile, not be cargo cult agile.

One of the reasons we might need coaches for a team is because of the changed manager role in agile.

In functional organizations, managers coached the team members on how to do their jobs better. (Okay, some managers did.) Development managers coached developers. Test managers coached testers. Project manager-managers coached project managers, etc. Each functional manager coached the people in their functions on how to do their functions better.

Some managers learned how to coach the functional people to perform better in teams. To be honest, that was often quite difficult. The organization rewarded the function, not the teamwork.

Agile is changing this mindset of “coach the function, let the teamwork take care of itself.” (Yes, that’s a generalization, and not fair. However, I see a lot of it.)

In agile, we want a product as a result of team effort. That leads us to think about the role of managers and teams and coaching in different ways. (Well, it does for me.)

If you are not aware of Human Systems Dynamics, let me introduce you to the ideas of Containers, Differences, and Exchanges. I read about this in Adaptive Action: Leveraging Uncertainty in Your Organization.

When people and projects choose agile, the managers have new and different roles.  People no longer affiliate with managers (the container part). They affiliate with projects. This means that manager-as-coach changes in any number of ways.

Instead of being able to, or even having the time, to coach people on their functional roles, the manager might create communities of practice, or other ways of encouraging people to learn about their role better. If the manager knows about the function, the manager can coach the people.

And, many managers only know about or have experience in their own functions, such as strictly development or testing or writing. I call these managers “ignorant.” That’s because unless a manager can see the entire picture (including the dynamics of a project, the manager might not realize the problem with the impediments the team faces.

Ignorant managers cannot create the environment in which a team can deliver working product. Yes, the team has responsibility for a significant part of that environment, especially working as a team to move features across the board. And, the manager creates the container in which the team works.

I’ve seen ignorant managers create these problems for the team:

You might see other problems in your organization. An ignorant manager cannot help the team or the team members at all, because the ignorant manager does not realize the problems these impediments cause.

The agile manager’s role changes, especially managers who “manage” technical teams. I wrote about this years ago in Agile Managers: The Essence of Leadership.

Agile managers help facilitate the environment for the team (possibly along with an agile project manager/Scrum Master or a program manager). They are servant leaders. They provide coaching and feedback and meta coaching and meta feedback. The manager’s role is about facilitating what the team members can deliver, to the team, to the product, and to themselves. It’s about inspect and adapt for team members.

That’s where we encounter the affiliation problem. Who do we want the team members to identify with? With the functional manager—who with good intentions—ask a team member to do work not on the board? Or, do we want team members to identify with the team? I vote for the team. (I vote for the team regardless of the approach, agile or otherwise.)

Managers might need coaches so they learn about what the team members do. Then, managers can provide feedback and coaching and meta feedback and meta coaching as someone who can see from the outside of the team. Managers can learn what the impediments are for agile (too-long duration commitments, resource vs. flow efficiency, HR and finance issues). Managers can help lead the organization’s agile approach.

And, many managers need coaching to do this: agile coaching and how the functions work in an agile team. That’s because we want managers to be the best managers they can be to help the organization move to agile.

When managers change what they do, they might need coaching to learn how, and to get the feedback to see the possibilities of their decisions. Management coaching is not about weakness. It’s about the realization that if we want to change culture, we change behavior. Not just team behavior. Management behavior is a key part of the agile transformation.

In part 3, I’ll address coaching and collaboration for middle and senior managers.

Categories: Blogs

Agile Tour Vienna, Austria, November 12 2016

Scrum Expert - Thu, 10/13/2016 - 09:30
The Agile Tour Vienna conference is a one-day event that aims at bringing together experts and practitioners interested in Agile software development and Scrum project management. The main conference language is German, but there are some talks in English. In the agenda of the Agile Tour Vienna conference you can find topics like “Effective User Stories”, “(How) do I do “real” Scrum?”, “Agile 1×1”, “Mobile Testing in Agile Context”, “Scaling Agile Delivery: Turning the Lights On”, “A UX Toolkit for the Product Owner”, “Given/When/Then-ready sprint planning”, “Test automation without a headache: Five key patterns”. Web site: Location for the Agile Tour Vienna conference: FH Technikum Wien, Höchstädtplatz 6, 1200 Vienna, Austria
Categories: Communities

Agile Tour Bangkok, Thailand, October 28-29 2016

Scrum Expert - Thu, 10/13/2016 - 09:00
The Agile Tour Bangkok is a two-day conference focused Agile software development and Scrum. The main objective of this conference is to promote to the Agile software development community in Thailand. Local and international Agile practitioners will share their rich experiences during the Agile Tour Bangkok. In the agenda of Agile Tour Bangkok conference you can find topics like “Mindmaps: A killer way to increase your test coverage”,”Agile Without a Name”, “Integrating Agile Concept Through Education”, “Advanced Lean Agile. Scrum beyond the Guide. Beyond Basics. Beyond a single framework. No Dogmas!”, “Enterprise Agile Journey with DST”, “Enterprise Scaling Strategy”, “Agile Business (Transform Your Organization Through Agile)”, “The Principles Of Agile Metrics”, “Agile and Waterfall from the view of Plato and Aristotle”, “Practical Guide for First Time Product Owners”, “Do and Don’t for Continuous Delivery”, “Agile transformation – The role of a QA”, “Enterprise Agile Pitfalls”. Web site: Location for the Agile Tour Bangkok conference: Montien Riverside Hotel, 372 Rama 3 Road, Bangkhlo, Bangkok 10120, Thailand
Categories: Communities

REPL, Scrum & the Wright Brothers

Scrum Expert - Wed, 10/12/2016 - 14:39
Jeff Sutherland makes a convincing argument of using Scrum outside of software development in his recent book Scrum: The Art of Doing Twice the Work in Half the Time. A full 111 years before Sutherland published this book, the Wright Brothers practiced scrum to outmaneuver better funded and more entrenched competitors. REPL driven development is a technique that comes to business software creation from the scientific computing community. REPL driven development takes the benefits of small iterations and immediate feedback and marries it with the change-proofing benefits of test-driven development. Taking the lessons of Sutherland and the Wright Brothers back to software, we will see how REPL-driven development aligns perfectly with their techniques. At the end of the session, you will know how to write code faster and better, and have a heck of a lot of fun doing it. This session will be using F# in Visual Studio 2015. If you have learned some F# and are eager to start using it in your day job, this session will use some techniques help you achieve that goal. Video producer:
Categories: Communities

Targetprocess v.3.10.1: New Visual Reports Editor, more Batch Actions

TargetProcess - Edge of Chaos Blog - Wed, 10/12/2016 - 09:24
Beta of our new Visual Report Editor

On-Demand users will be able to switch to the beautiful beta of our new Visual Report Editor from Report Settings.

With this editor, you will have a lot of useful and easy options:

  • You can drag-n-drop fields in reports to edit them and explore your data 
  • Aggregate fields, and make title and sorting changes with one click
  • Important milestones and threshold lines can be added from field annotations
  • Browse and edit chart data with the built-in visual editor
  • Easy custom calculations via a formulas editor with full autocomplete 

Read more at this dedicated release post for the new Report Editor

Batch Actions: Text, Number custom fields, batch change Effort, link Relations

In v.3.10.1  you can reset or set new efforts for a group of selected cards. Only roles, who are common for all selected cards, are available in a batch action panel. Here you can set a new effort number or reset it to zero. If you see a certain number in the Effort field, it means that all cards in the selection have the same effort set. The 'Set new' placeholder means there are different Effort value sets in different cards (if the selection is for a given role).

batch effort

You will also be able to batch attach any Targetprocess entity to a group of cards as a Relation.

batch link relatioin

We've also added support for two more types of Custom Fields (in addition to drop-down lists) in the Batch Actions panel: Text and Number. We're now working on Date, Checkbox and Multiple Selection Custom Fields support.

Clone Dashboards

Somehow, the Clone action was missing from Dashboards. We fixed this inequity - you will now be able to make a copy of any Dashboard.

Clone Dashboard

Fixed Bugs
  • Fixed Custom Field Constraints mashup to support custom teams workflow states
  • Fixed '0' drop-down list value wich couldn't be set properly
  • Fixed 'Share report' option
  • Fixed ban on adding users if their email is the same as a deleted user had
  • Screen Capture Extension: login issue fixed
  • Fixed problem with Copy to project / Convert not working if there is a deleted user assigned to a card or its child entity
  • *.m4a attachments now download correctly
  • Fixed Dark skin for TV to show view name properly
  • The *.Count().* DSL filter supports more complex predicates. Example: 'UserStories.Count(Feature.Name.Contains('Web') and Effort > 0) > 5'
  • Added the option to open URLs with the Targetprocess site domain from Custom fields in a current window
Categories: Companies

New Visual Report Editor

TargetProcess - Edge of Chaos Blog - Wed, 10/12/2016 - 08:43

We are happy to announce the beta release of our new Visual Report Editor for all On-Demand accounts (with the exception of private clouds, for now).

You may find the following features to be useful:

  • Editing reports and visually exploring your data can now be done simply with interactive fields and drag-n-drop
  • Aggregate fields, and make title and sorting changes with one click
  • Important milestones and threshold lines can be added using field annotations
  • Browse and filter chart data using the built-in visual editor UI
  • Custom calculations can be done easilly via a formulas editor with full autocomplete. This will bring your creation of complex calculations to the next level
  • Low-level data details are available within the tooltip data reveal extension

Here's how you can try out the new Report Editor:


We will really appreciate your feedback on this beta release of our new editor. What do you like about it? What could be improved? Let us know what you think at

Categories: Companies

A Linux User Reviews our Git GUI

About SCRUM - Hamid Shojaee Axosoft - Tue, 10/11/2016 - 22:10

It all began about a year ago. The sea was calm, and the wind was blowing steadily. I saw a small object floating away on the high seas, and I quickly grabbed my harpoon to pull it out of the water.

Upon close inspection, I saw a box with a greenish (almost blue) monster, with tentacles carved in it, and even though it was just a carving, its eyes seemed to pierce my soul. I took a deep breath and, after gaining some courage, I opened the box, and then the whole world changed…

The Kraken had been unleashed, and I controlled the great beast of the seas!

Leaving the metaphorical explanation of how I found this piece of software, I should probably tell you why GitKraken is my Linux Git GUI of choice. Here are some specific reasons:


Why would I bring up Linux? For two reasons: Linux Git GUIs aren’t that good, and the real competition doesn’t have a Linux version. Let’s unpack this statement, shall we? First of all, most Git GUIs for Linux make me feel like I’m back to Windows 95, in need of multiple windows to do a simple commit and push.

I want to go to any OS, download my favorite app and use it; GitKraken gives me just that.

Others fill the screen with views that I only use once every four months and exist only because I messed up while reverting a commit. Other Linux GUIs are old-fashioned or complex and crowded.

GitKraken offers a modern view of how Git should be used and ends the starvation for a good Linux Git client.

Secondly, most of us know one or two really good Git GUIs: for example SourceTree or GitHub for Windows. These are two pieces of software that I used for quite a while, but when I moved to Linux they were missing. I want to go to any OS, download my favorite app and use it; GitKraken gives me just that.

User Interface

Let’s backtrack a bit to where I said, “GitKraken offers a modern view.” If you’ve never tried GitKraken, you are probably thinking, “Yeah right… that’s what they all say.”

Well, here’s what I say: just try it. Commit some code, then revert the commit. Did you do it? How hard was it? A push of a button? Really, it’s that that simple.

If you’re like me and prefer it simple, this is for you. Just open the app, write your message and commit the hell out of the repo.

In addition, there are no weird hidden menus, and drag-and-drop is also a very nice feature. Tell me I’m not right. Just try it.

Check out that drag and drop feature. Rad.
Check out that drag and drop feature. Rad!

Perhaps you’d like to see more controls so that you can easily do those weird commands Git offers. Or maybe you prefer the CLI because you want to master all the commands.

But if you’re like me and prefer it simple, this is for you. Just open the app, write your message and commit the hell out of the repo. Don’t forget you can always undo the commits that you mess up.

The Dark Side

If there is light, there must be darkness, and yes, even GitKraken has its weaknesses. One weakness that I’ve experienced is the hooks. When pushing in GitKraken, hooks (in .git/hooks/) are not triggered, which made me stop using GitKraken in a specific project.

Another weakness is that there is no forum for users to report issues (akin to something like Stack Overflow.) Don’t get me wrong, GitKraken is very active with the community; just see their blog and Twitter feed.

It’s awesome to see such proximity between a company and the common folk, but when more technical problems arise, there isn’t really a place to go, other than to contact support if you are using the Pro version.

Editor’s Note: We launched our GitKraken Slack Community just after this article was written. This is a great place for users to discuss tips and ask/answer each other’s questions.

In conclusion, if you like a modern design, a handy undo button, a beautiful layout, and Linux support, then GitKraken is for you. Try it and see, you’ll be amazed!

Categories: Companies

Forty8Fifty Labs Launches Splunk Connector for Atlassian JIRA

Scrum Expert - Tue, 10/11/2016 - 18:59
Forty8Fifty Labs has announced the Real-Time Splunk Connector for Atlassian JIRA Service Desk. The new solution leverages advanced analytics and reporting to provide a big picture view across all service desk environments so DevOps teams can better understand the incident trends that often create persistent or intermittent service issues. The Real-Time Splunk Connector for Atlassian JIRA Service Desk from Forty8Fifty Labs can trigger enhanced, real-time alerts within HipChat to arm development teams with the information and context they need to build system performance and reliability. Leveraging real-time Searches in Splunk to trigger configurable levels of service incidents associated with JIRA Service Desk, the new product empowers teams to close the loop on responses to issues taking place in their environment. Taking the value a step further, the new product also provides rich visual data analytics on both the operational occurrences taking place along with the Service Desk experience associated with it. This provides development and operations teams with an anytime, anywhere view of the state of their service request and delivers the detailed information needed to act fast. Key features of the Real-Time Splunk Connector for Atlassian JIRA Service Desk include: * Automated incident creation driven by real time search events * Relevant troubleshooting detail linked directly to incident from inception * Integrated alert notification to HipChat Rooms (when using HipChat) * Rich Visual Data Analytics of both Incidents Patterns and Service Desk Experience
Categories: Communities

DSDM Consortium Renamed as Agile Business Consortium

Scrum Expert - Tue, 10/11/2016 - 18:25
The DSDM Consortium, author and custodian of the world-leading DSDM Agile Framework, has announced a new identity and a major new Agile approach. The Agile Business Consortium unveiled its new name and look as it launched the Agile Business Change Framework, designed to support businesses and organisations in adopting Agile at any organisational level and on any scale. Agile Business Consortium CEO Mary Henson said: “Some years ago, Agile became the mainstream approach to software and systems development and in those fields it’s now used more than any other approach. Increasingly, businesses recognise the benefits of adopting Agile methods in many different parts of the enterprise but struggle to understand how to enable it, implement it and ensure robust governance. “The Agile Business Consortium has evolved to address those challenges and, particularly, to develop the Agile Business Change Framework – a new framework that will enable businesses and organisations to take an Agile approach wherever in the enterprise it’s needed and on whatever scale it’s needed.” Building on more than 20 years’ experience in developing DSDM’s highly successful project management and programme management frameworks, the Agile Business Consortium has been developing the new Framework with selected partners and early adopters such as PwC, Tata Consulting and others. It will continue to build a community of like-minded partners to progress the Framework and will provide supportive training through a network of accredited organisations.
Categories: Communities

Coaches, Managers, Collaboration and Agile, Part 1

Johanna Rothman - Tue, 10/11/2016 - 17:15

There was a fascinating Twitter conversation last week when I was busy writing other things. (I also find Twitter to be a difficult-for-me arena to have a conversation. I need more than 140 characters.)

The conversation started when Neil Killick tweeted this:

orgs need coaches not because “agile is unintuitive”, but because effective sw delivery is a team game requiring folks at their best.

I liked that and retweeted it.

Mohinder Khosla asked (quite reasonably, in my opinion):

Do we have stats that this is real? Just saying

Mohinder, I am sure we do not have stats. We rarely do what I would categorize as real research in how software product development works. That’s because we continually learn and even if we start a new project with exactly the same people, we have learned to work together in previous projects. If we don’t keep teams together, we have to relearn how to work together. (See Hackman’s Leading Teams book for this and much more insight on teams.)

Agile challenges all of our previous assumptions about how software product development works.

  • We think in product, not just project. See terms as releasing, product owner, and MVP.
  • We think in flow efficiency, not resource efficiency.
  • We integrate all of the work we might have done as phases into small stories that we release often.
  • We invite change, we don’t try to control it
  • and much more…

Agile is a mindset change and a cultural change. (See When is Agile Wrong for You?)

One of the big changes in agile is that we work as a team. We work as a team to move work across the board. We don’t hand off work from developers to testers. We don’t hand off work from architects to developers. We don’t hand off work from testers to operations.

Can each team do that now? Probably not the first time they try to use agile. This notion of the cross-functional team being the team in question challenges everything we, our managers, and our organizations “know” about product development.

Coaches can help teams and managers learn what it’s like to create the agile mindset and an agile culture. Do you need a coach? Maybe not. Here are some questions I have asked my clients when they asked whether a coach would be useful for them:

  • Do you have a cross-functional team? Or, is it a team of developers, followed by a team of testers, etc.
  • Can you create features as one cross-functional team, by yourselves? (You might not be doing this now, but can you? Or, do you need other people across the organization?)
  • Does the team demonstrate on a regular basis? (My guideline: at least once every two weeks.)
  • Does the team retrospect on a regular basis? (My guideline: at least once every two weeks.)

Notice that these questions are about team collaboration and delivery.

Agile creates transparency. We can see when a team is not “performing.” I put that in quotes because often the environment is what causes teams to not “perform.”

Some teams have trouble working as a team. Coaches can help. Other teams cannot answer yes to my four questions. If so, coaches can help the team and the managers. Can the organization help itself? Of course. Would it be easier with a coach? Probably.

You don’t need agile coaches to be successful. You can do it yourself. And, if you look at people and teams who fit your definition of success, they will often tell you they have coaches. (I do.)

Agile teams deliver working product on a regular, frequent cadence. They can use flow-based agile or iteration-based agile to do so. It doesn’t matter.

When teams deliver on a regular basis, they work as a collaborative team. That idea and practice might be quite new to everyone in the organization. Coaches might help.

The next post will be the role of managers in coaching in an agile environment.

Categories: Blogs

Using Sprint Data to Modify Behavior

Scrum Expert - Tue, 10/11/2016 - 16:39
In an ideal Agile world, the Scrum team can complete all user stories tasks that it planned for the current sprint. The real world is however different. In this article, Scott Lively explains how to use the sprint data to modify the team behavior. In his introduction, Scott Lively explains the feeling of having some user stories not completed during a sprint and the importance of analyzing the sprint data to improve. The article will focus on the percentage of story points coming from new content versus points from carryover content, and the percentage of points added after sprint planning. His analysis of the issues causing the fact of having often carryover user stories at the end of the sprints led Scott Lively to explore the following improvement opportunities: * Writing smaller and better user stories to improve the sprint estimation process * Taking more time to understand the scope of user stories * Cross-training for the Scrum developers so that there are more resources available for all the different activities and technologies involved in software development * Having a mid-sprint assessment meeting to determine of how likely it is that everything planned for the sprint will be completed. This could lead to change the sprint plan and it also gives the Scrum developers another explicit opportunity to help each other. His conclusion is that “The bottom line is that we need to continue measuring how we do sprint over sprint. Further, we need to be careful about the behaviors [...]
Categories: Communities

Don’t Defer a Meeting Because One Person Can’t Attend

We're entering flu season. No, no, I feel fine. And you won't catch anything from me just by reading this.

But flu seasons means some of your teammates are bound to be sick soon. And that means they'll occasionally stay home and miss a meeting.

What should a Scrum team do when the whole team will not be present for a meeting?

In most cases, everything should roll forward as planned. Let's look at each of the common Scrum meetings.

The Daily Scrum

A daily scrum should never be cancelled simply because a person (or two) cannot attend. The meeting will still be valuable for synchronizing the work of those who can participate. When someone calls or emails to say they'll be out sick, the person can--if necessary--provide a minimal update or pose a question to the team. This would be something like, "Tell Lena I've just about finished the code she's waiting on. I just want to do a few more tests before I check it in."

The Sprint Review and Retrospective

I don't recommend canceling a sprint review, and I would never cancel one because a team member was out sick. I have, however, canceled a few sprint reviews that were being given to a client on a contract development project when the key client stakeholder could not participate.

I'd prefer to proceed with only the other stakeholders present. But sometimes the client prefers not to. That mostly happens when one client participant is the boss and that's who cannot attend. The review could proceed with just the other stakeholders. But if they're going to say things like, "We should hold off on that decision until Martin can be here," I think it's OK to reschedule the review as long as that isn't a regular occurrence.

I would also never reschedule a sprint retrospective. Those who are able to participate should proceed as planned.

Product Backlog Refinement

Product backlog refinement meetings can be rescheduled if necessary. Since these don't occur on the first or last day of a sprint, they're much easier to move. I would avoid rescheduling this (or any meeting) very often because any rescheduled meeting can feel like an interruption. But, if the product owner or any other truly necessary participant will be out sick, a backlog refinement meeting is OK to reschedule.

Sprint Planning Meeting

In general, I would not reschedule a sprint planning meeting because someone is sick. If the person is truly the superstar of the team and we absolutely cannot plan a sprint without that person, go ahead and re-schedule the meeting for the next day. But then spend the rest of the day in an impromptu retrospective discussing how to get out of the problem of being so dependent on one person that the team cannot even plan (let alone, do) its work.

Even if it is the product owner who cannot participate in the sprint planning meeting, a team should be able to plan one sprint without their product owner. If a team does everything I advocate (such as story-writing workshops, product backlog refinement, estimating to gain shared understanding of a product backlog item and so on), the team will have a good understanding of each product backlog item by the time it comes into a sprint.

Sure, they will usually have a few questions left for a product owner to answer during sprint planning. But the team will largely understand what needs to be done to deliver the highest priority product backlog items. And so, they can plan a sprint even without the product owner.

As a precaution, the team might opt to plan the sprint a bit less full than normal. That leaves room for items to take a bit more effort if needed when the product owner returns and clarifies the last few open issues. Or it allows a product owner to add a user story or two when they return to work. Either approach allows sprint planning to proceed and to be fine-tuned when the product owner is available.

What Do You Think?

Would you ever cancel one of Scrum’s standard meetings? Under what circumstances? Please share your thoughts in the discussion below.

Looking for more information on handling Scrum meetings?

Sign-up for Mike's weekly tips and also receive his PDF "Guide to Handling Absences from Scrum Meetings.”

Categories: Blogs

Scrum Knowledge Sharing

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