Skip to content

Feed aggregator

GitKraken V1.5 Gives You Even More Control

About SCRUM - Hamid Shojaee Axosoft - Thu, 07/28/2016 - 18:41

Upgrade to GitKraken Pro

The GitKraken team has been working tirelessly on this latest release to bring you so much goodness! We’re excited to announce a couple new features you’ll be head over tentacles for. And we’d like to introduce you to GitKraken Pro: your favorite Git client with even more control and options.

As GitKraken has evolved with each release, we’ve started to see just how much it resembles its cephalopod cousins, which actually reside in the sea. Let’s take a look, shall we?

It’s time for you to dive into the murky depths with GitKraken.

Gourmet Kief GitKraken Pro: More Options + Power Fast Fact: Octopuses have about 200 suction cups covering their tentacles, giving the octopus a grip of up to 100 pounds per square inch.

Wanna be that strong? Of course you do. Which is why we’re thrilled to announce a new edition of GitKraken called GitKraken Pro, which will give you even more powerful tools for working with Git.

Once you’re done finding out about all the new features available in V1.5, be sure to check out this blog post dedicated entirely to the launch of GitKraken Pro! You’ll even find out about our launch fundraiser! Spoiler Alert: 100% of first month revenues from the sales of GitKraken Pro will be donated to an open source technology project that is helping those affected by Type 1 diabetes.

And GitKraken itself will continue to be an incredibly powerful, luxurious and FREE Git client! Pro Merge Tool Provides More Control

If you’ve had GitKraken for any amount of time, you already know that it has a merge tool. If there’s a conflict, you can resolve it in app—easy as pie. If you are merging two versions of code and there’s a conflict, GitKraken lets you know.

Up until now, you had to take the lines of code as they were already written; you could not edit them. However, now you can make edits when you upgrade to GitKraken Pro.

The Pro Merge Tool takes things to a whole new level. It not only lets you know that there’s a conflict, but you can now go into the merged code and edit content in the output. Let that sink in for a second.

merge conflict edits The Pro Merge tool lets you edit your code. The freeform editing is on par with stand-alone tools. You usually have to do this with a third-party tool, but now you can stay in app. For day-to-day use, this will be really valuable and save a lot of time.David Koontz, GitKraken Developer at Axosoft

In addition to being able to edit, syntax highlighting is a welcomed addition in both the free and pro versions. “This is just the cherry on top,” reports Kyle Smith, GitKraken Developer at Axosoft. “It makes it so much easier to look at the file,” he says.

“Merge conflicts are the scariest part of anyone’s interaction with Git,” says Smith. “There’s always a risk of losing some code. So, when you’re the person merging the files, you must do it in a way that preserves those two changes,” he reports. “Syntax highlighting eases the pressure in dealing with that.”

Now you can kiss that third-party merge tool goodbye!

Profile Switching like a Pro Fast Fact: The Mimic Octopus can appear to change itself into at least 7 different types of animals in order to catch prey or elude predators.

Sometimes you may be working on a project at work and sometimes you may be working on a personal project. We get that; we do it too!

That’s why you can now have multiple profiles in GitKraken Pro. You can change easily from “Work Dev” to “Home/Coffee Shop Dev” and still retain your preferred settings.

Profile switching all Profile Switching allows for an easy transition between work projects and personal projects; it even saves your preferences!

This Pro feature helps you keep your work and personal projects separate. “It can get really confusing if you are using a ‘work’ profile and working on something for your personal satisfaction,” says John Haley, Lead GitKraken Developer at Axosoft. “This is really helpful if you use the same computer for both work and personal projects. It’s now easy to switch between the two.” John Haley, Lead Developer at Axosoft

With this Pro feature, if you work on a project that has nothing to do with your place of employment—or perhaps if your place of employment doesn’t necessarily like you co-mingling your personal projects with work projects—you can now keep them totally separate.

“In the standard version of GitKraken, you can have both types of work,” Haley says, “but it’s mixed with your other projects. You can certainly open a personal repo under a work identity if you want. But Profiles make it obvious what you’re working on,” he concludes. The Pro version even lets you select unique icons to identify each profile.

You can even change your icon when you switch between profiles!

And, let’s be honest, you may have different work patterns when you’re at home than when you are at work. “At work, your fetch intervals could be lower than when you are at home because if someone commits, you may want to see that right away,” says David Koontz, GitKraken Developer at Axosoft, who also worked on this feature.

“You can tweak how GitKraken operates,” he continues. From themes, to fetch intervals, to where your windows are docked. Your profile retains this information. It remembers how you want to work and where you’re working. Isn’t that smart?

Pro Support: Because You’re Not Alone Fast Fact: Mother octopuses stay with their eggs for more than 50 months, making sure they hatch into tiny little octopuses.

Prior to this release, our Success Team (Yup, Axosoft has a Customer Success Team rather than a “Support” team) has been listening to the conversations and questions on Twitter and responding when possible.

With the launch of Pro this week, we are now offering personalized, guaranteed support to those who have Pro subscriptions, in addition to receiving your feedback. Simply submit a request or send us an email and we’ll get back to you as fast as possible.

So that about covers the new features you’ll see when you upgrade to GitKraken Pro!

Upgrade to GitKraken Pro

Here are new features that are available to all GitKraken users!

Tree View Helps You Visualize Fast Fact: The eye of the octopus is always horizontally aligned so it can correctly visualize its surroundings even though its body could be at any angle while swimming.

Lots of changes to a repo means lots of file names. And, let’s face it; file names are the last thing you need to be deciphering when you’ve been staring at code all day. Getting ready to make a commit could become confusing when you have to figure out the location of specific files. Stress no more! Tree View is available for all GitKraken users.

You can end up with a large file structure containing many folders and subfolders. In fact, a lot of files can have the same name and reside in different folders. Some files are code, some files are tests for that code, and some could be images. Now, when you use the Tree View option, instead of seeing the full paths that may be very long, you’ll see something that resembles a folder tree, much like what you would see in your OS.

You can expand and collapse all folders, just take a peek at one folder, or view a few at a time. Perhaps one of the best parts of this feature is that Tree View allows you to stage an entire folder at once.Jordan Wallet, Axosoft GitKraken Developer stage-by-folder-file-tree-view Not only does the Tree View allow you to clearly see your files, you can stage an entire folder easily.

Additionally, Tree View lets you see the differences between similarly named folders. This ends fumbling around for good! “The Tree View gives you context,” Wallet explains. “Any folder that’s collapsed will give you a summary of how many files have changed and in what way. You can also expand them and see the subfolders,” he concludes.

Please Create an Account Octopus vs Squid vs Kraken vs Cuttlefish. Help us keep track.

You’ll quickly notice something new when you now log into GitKraken. We’re asking you to create an account. We know, we know… But we have pretty solid reasons for adding this.

GitKraken has always required an email address for registration since the beta, and after much debate in the Axosoft dev room, we decided to transition to accounts for all users. This will improve your experience with installing GitKraken, and allows us to better implement new features and services in both the free and Pro versions of the app.

Creating an account helps us create a better experience for you.

As you are creating your account, please know:

  • GitKraken will continue to be a free product that we actively develop and improve. We want it to be the best, free, cross-platform Git client available.
  • Privacy is always a concern. Our privacy policy for GitKraken explains what information we collect from users and what we do with it.

So, that’s it. (It’s a lot, we know.) Please keep your feedback coming. We do read through it! To see all that GitKraken has to offer, please check out our features page.

References: Octopus facts from Monterey Bay Aquarium’s website and my brain.

Categories: Companies

Introducing GitKraken Pro

About SCRUM - Hamid Shojaee Axosoft - Thu, 07/28/2016 - 18:40

As a product guy (and the official VP of Product at Axosoft), it’s always super exciting for me when we launch something new. Today, I have a couple of exciting announcements. Let’s jump right in, and then I’ll give you a little background about each announcement.

GitKraken and Nightscout logos Axosoft is teaming up with the Nightscout Foundation to help raise money for an open source diabetes project.

Upgrade to GitKraken Pro

Ok, so let’s get into the announcement details!

GitKraken and GitKraken Pro

About two years ago, Axosoft started work on a Git client that would change the way developers interact with Git. While the Git Command Line Interface (CLI) provides a powerful means of interacting with Git repositories, it’s also a maze of convoluted, verbose commands that are hard to remember and extremely error prone, which make it difficult to harness the power of Git.

A couple of my colleagues at Axosoft felt there was a much better, more visual way to interact with Git and to see the history of interactions. The result was the introduction of GitKraken about a year ago.

GitKraken immediately became a runaway hit with a user base that quickly blew past 100,000 software developers worldwide.

Axosoft has made a huge bet on GitKraken, investing millions in its development, and we are hell-bent on making GitKraken the #1 Git client in the world. Based on user reactions and the feedback we’ve been getting, we are well underway to achieving that goal:

Trying out @GitKraken, and I’m impressed. AFAIT, this thing actually lets you do almost anything you can do from the CLI.

— David Baumgold (@singingwolfboy) June 21, 2016

Best Git client EVER. #Axosoft @GitKraken And it’s #crossplatform

— Elijah Duffy (@ENDev15) June 22, 2016

@GitKraken the first git UI I feel like I can trust. Elegant, responsive,cross platform. It takes a lot to get me off console…but this wow

— Steven (@stvndall) May 28, 2016

@GitKraken has given me the confidence to navigate and learn Git using an approach supported, not hindered, by the GUI. #git #awesome

— Jonathan Storey (@jonistorey) June 26, 2016

Really liking @GitKraken! Sourcetree has a thing or two to learn from it. early days still but looking like I may have a new favorite.

— Matheus Guimaraes (@mdefineg) February 13, 2016

@GitKraken The fact that I am using a GUI for my git operations IS actually extraordinary… So well done, you convinced me

Categories: Companies

The ‘Game’ of Agile Compared to Football: Training Camp & Preseason

The Agile Management Blog - VersionOne - Thu, 07/28/2016 - 14:30

The Game of Agile Compared to Football

More than 30 years ago Hirotaka Takeuchi and Ikujiro Nonaka wrote an article titled ‘The New New Product Development Game,’ which compares product development to rugby. This year’s NFL draft inspired me to make a similar analogy to American football. This is the second in a series of articles comparing agile and football around the major events including: Draft Day, Training Camp & Preseason; Kickoff Game; and Super Bowl.

Click here to read the first article comparing agile to Draft Day.

Once a football team is formed, they establish ground rules and set expectations about scheduled training sessions at the same facility.

  • Once an agile team is formed, they establish Sprint 0 Activities including:
    • Team Charter (Members, Name, Values, Sprint Planning day and duration, Core working hours, Ground rules for communication)
    • Schedule recurring meetings (Scrum ceremonies, Backlog refinement, Scrum of Scrums)
    • Definition of Ready
    • Definition of Done
    • Coding standards
    • Estimation standards
    • Production Support Severity Levels

The football staff in charge of equipment establishes their system to support the team during the season (cleaning uniforms, transporting and supporting sideline mics and headsets, physical therapy and training equipment, water for the game, etc.)

  • An agile team establishes a support system. For VersionOne this means unifying strategy, development, and delivery in order to accelerate the delivery of business value. The VersionOne Enterprise Agile Platform’s agile ALM, DevOps, and integration solutions provide organizations with insight and traceability from product inception to delivery.

Playbooks are distributed that explain the drills that the players will be learning and practicing. The team is then sent through the drills over and over during practices to build muscle memory. The coaches may find that some of the plays need to be adjusted so they update the playbook based on what they’ve learned through practice.

  • Organizations create Agile Playbooks that describe how they are applying the agile values, principles, and guidelines around the methodologies they are applying. Teams will include a section that contains information gathered during the Sprint 0 activities. The Agile Playbook becomes the guide for directing new hires on how the team will work together.

Before the season starts, football teams will play several exhibition games. These provide experience for players who are not used to playing in front of large crowds and an opportunity for management to evaluate new players.

  • When rolling out an agile transformation, it’s common to conduct a pilot program with 1-2 teams. The teams follow the Agile Playbook and provide frequent feedback. It’s better to work out the kinks at the beginning of the transformation rather than jump into the game with both feet.

Stay tuned for the rest of the articles in this series:

  • Kickoff Game – September
  • Super Bowl – February

Find out how VersionOne can partner with you to build winning agile teams for successful agile transformations.

The post The ‘Game’ of Agile Compared to Football: Training Camp & Preseason appeared first on The Agile Management Blog.

Categories: Companies

Books with Agile Practices and Tips

Ben Linders - Thu, 07/28/2016 - 09:54

Agile Practices and Tips Books BundleA new bundle of books with agile practices and tips has been released on Leanpub. Buy these books with a 40% discount!

The bundle includes six great books from eleven authors, helping you to make your agile journey easier to travel, more successful, and fun!

  • With plenty of exercises for your personal retrospective toolbox, Getting Value out of Agile Retrospectives will help you to become more proficient in doing retrospectives and to get more out of them.
  • A Toolbox for the Agile Coach:  96 Visualization Examples showing how great teams visualize their work.
  • The tools and techniques provided in the Forming Agile Teams workbook offer an alternative-proven way to add more structure, transparency and visibility to the work that you do when Forming Agile Teams, by combining visual explanations with techniques and tips to support Scrum Masters crucial role within the organization.
  • The Scrum Master Workbook Part 1 provides 15 weeks of accelerated learning. It teaches you ways to deal with conflict, bugs, interruptions, meetings and many more topics.
  • Patterns of Agile Journeys shares stories and patterns to help you recognize situations you may find yourself in on your own journey. Use the tips in this book to reinforce or counteract the patterns you see.
  • The book Continuous Improvement makes you aware of the importance of continuous improvement, explores how it is engrained in agile, and provides suggestions that Scrum masters, agile coaches, well everybody, can use in their daily work to improve continuously and increase team and organizational agility.


Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Together these books provide many useful tips and practices for your agile journey. Buy them for $40,77 (regular price is $67,95).

There’s also the Agile Retrospectives Books Bundle with six great books that will make your agile retrospectives rock, and the Valuable Agile Retrospectives – All Languages Bundle which contains all language editions of my successful book Getting Value out of Agile Retrospectives.

Categories: Blogs

Customer Spotlight: Psyonix

About SCRUM - Hamid Shojaee Axosoft - Wed, 07/27/2016 - 16:08

Attention video game lovers and software developers alike! Have you heard of the San Diego-based video game developer company, Psyonix? If you haven’t, it’s about time you found out about them!

They are the creators of the popular video game, Rocket League, where rocket-powered cars speed around an arena in pursuit of a ball. The object? To get the ball in the other team’s goal. Think of it as a kick-ass, virtual soccer game where you play as a super-charged custom car or truck. Oh, and they can fly!

rocket league car Players of Rocket League enter a field where cars can be customized and yeah, you can fly.

How do I know it’s a kick-ass game? Because I play it on a weekly basis—and as I recently tweeted—yell at the TV because I keep missing goals. It’s seriously addicting and a lot of fun!

Since this game is so cool, and since the company uses Axosoft to help make it great, I wanted to find out more about Psyonix’s story….

Experiencing History Being Made

According to Greg Nichols, QA Manager at Psyonix, the roots of the company were formed a little over a decade ago, in North Carolina. Members of the core team got started in the industry by modding the game, Unreal Tournament 2003 and developing new and improved vehicle physics for the title. Their impressive work on adding to this already-released title got them a nod from the game’s creator and designer of the Unreal Engine, Epic Games.

The (future) founders of Psyonix were hooked on the Unreal technology and what it could mean for the gaming world and its future. Psyonix has always specialized in and prefers working in the Unreal Engine. Their proficiency in this code has led them to become an industry leader in Unreal tech and design.

Because of their vast knowledge and experience in this system at such an early part in the company’s lifespan, opportunities would open up for them down the road that really allowed Psyonix to grow and find its stride.

In December of 2009, the group decided to move to California from the East Coast because that’s what everyone does when pursuing big dreams, right? So they moved to San Diego and the group got their taste of video game-making glory!

They began doing work-for-hire; helping to develop big names in the gaming world like Gears of War, Mass Effect 3, XCOM: Enemy Unknown and Bulletstorm.

Working this way, however, forced Psyonix to use the hiring company’s project managers, their strategy to manage development, as well as their scheduling.

The Beginnings of a Blockbuster

While assisting on blockbuster titles was great, the team always wanted to make their own IP and do it their way. In their spare time, they developed a game called Supersonic Acrobatic Rocket-Powered Battle-Cars (we’ll call this Rocket League V.1), which was released on the PS3 in October of 2008.

While it wasn’t a blockbuster smash when they released it, the team noticed that they had a decent amount of fans in the gaming community who enjoyed  the game. They were loyal and appreciative, and the type of fans that would give feedback to help make the game better.

Axosoft helped them get organized with tracking bugs and Psyonix was ready to get the alpha release of Rocket League out to their loyal fans to test.

“A family developed through that game,” reports Nichols. The team grew close while the work became more intense. As a result, Psyonix experienced more success internally and externally.

team of people The Psyonix team believes that collaboration and communication lead to success.

The studio continued on to other projects, though kept the idea of building on Battle-Cars as an option, recognizing the game had a small but dedicated fanbase that provided them with ideas for expansion.

However, just a few years ago, they decided to make a sequel to the game. They went back to their loyal community, took their feedback, listened to their voices and fixed the bugs. Shortly after, the team went into full swing with developing the sequel to Supersonic Acrobatic Rocket-Powered Battle-Cars: The title? Rocket League.

Choosing Tools Wisely

While they were masters of Unreal Engine software, the same couldn’t really be said about their internal tools. Psyonix knew from experience they needed software to help them debug and plan, but what could they use? The team had worked with many different types of project management software over the years but knew they needed something just right for them.

Our team likes lists of what they need to do, they like to get the details quickly and move seamlessly. They want to get their workload, and just put their heads down and power ahead. Greg Nichols, QA Manager, Psyonix

They needed something inexpensive, but with the ability to customize workflows and see team communication on defects. This is where Axosoft and Psyonix joined together.

Axosoft helped them organize their bug tracking and Psyonix was ready to get the alpha release of Rocket League out to their loyal fans to test.


The alpha was a smash and the public beta was soon released in 2014! It proved to be a huge success; not to mention this beta was done outside of their knowingly-loyal community in which the alpha was tested.

Rocket League on Xbox Rocket League is available on Xbox One!

On July 7, 2015, Rocket League was released for the PlayStation 4 through the Instant Game Collection on PlayStation Plus, as well as on PC through Steam. More fans of the game emerged, word of mouth spread on how AWESOME it was to play, and the community grew by leaps and bounds.

We work hard. We make games we like to play. Being done with work for the day and going home excited to play awesome video games that we made, that is why we do it.Greg Nichols, QA Manager, Psyonix

A few Axosoft developers even played it and raved about it before knowing that the software they make helps create the game they love!

Now, with Rocket League celebrating their recent one-year anniversary on July 7th, 2016, they have been nominated for over 150 “Game of the Year” awards, boast a community of over 18 million users and 1.1 million daily active users, and have releases on  Xbox One, PC and PS4.

Categories: Companies

Lean-Agile Straight Talk: The Doctor Is In! A Conversation on Lean-Agile Budgeting. With Guy Beaver and Kelley Horton

NetObjectives - Wed, 07/27/2016 - 16:06
 The Doctor Is In! A Conversation on Lean-Agile Budgeting with Guy Beaver and Kelley Horton The Doctor Is In! is a weekly webinar and podcast that offers listeners the chance to meet and ask questions of Net Objectives consultants and thought-leaders on a variety of topics. In this show, Guy Beaver, Kelley Horton, and Jim Trott discuss Lean-Agile Budgeting. It is a critical though often an...

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

Version 7 Beta 5

IceScrum - Wed, 07/27/2016 - 11:20
7.0.0-beta.5 A new iceScrum 7 beta is here: 7.0.0-beta.5. As planned, this version comes with Source Code Management and Continuous Integration (Git, SVN, Jenkins…). For the moment, they work like before (here is the old documentation for those who don’t know about these integrations: Git & SVN – Jenkins). That means that you can know…
Categories: Blogs

Agile 2016 Video Podcasts!

Leading Agile - Tue, 07/26/2016 - 22:01

This week Atlanta is hosting the biggest Agile event ever put together. There are 2,500 people attending Agile 2016! If you weren’t able to make it, you don’t have to miss out. LeadingAgile is doing video podcast interviews with the speakers and thought leaders who are helping to reshape the way we work.

You can watch the videos on Vimeo or Facebook.

And keep checking back… we’ll be posting new videos all week long.


The post Agile 2016 Video Podcasts! appeared first on LeadingAgile.

Categories: Blogs

The Executives (Step-by-Step) Guide to Leading Large-Scale Agile Transformation #agile2016

Leading Agile - Tue, 07/26/2016 - 21:55

In case anyone is interested, here is my talk from Monday’s session at Agile 2016. Thanks to everyone that made it out. Had a great time.

The Executives Guide from Mike Cottmeyer

The post The Executives (Step-by-Step) Guide to Leading Large-Scale Agile Transformation #agile2016 appeared first on LeadingAgile.

Categories: Blogs

Extensions and Simplifications for Calculated Custom Fields

TargetProcess - Edge of Chaos Blog - Tue, 07/26/2016 - 15:52

We’ve made a few extensions to Calculated Custom Fields with some of our recent releases (3.8.9 and 3.9.0). We also simplified the formulas required for Boolean expressions and calculations with potentially null values. I’ve defined these terms below in case you’re not sure what they are.

Calculated Custom Fields: Used to create your own metrics for custom fields in Targetprocess.

Null value: A value which is unknown, e.g. hours of effort remaining for a project which has not been started. Please note that null does not equal zero; it’s simply an unknown variable. A nullable expression is any calculation with a potentially null result.

Boolean expression: This is basically just a true / false statement. If a field generates a yes or no answer, it’s probably using a Boolean expression.


Nullable Expressions:

We’ve extended Calculated Custom Fields to work much better with nullable expressions by adding an IFNONE operator.  This has simplified the formulas needed for such calculations by removing some of the developer terms which were formerly required, such as ternary operators.

So, when you need a default value for a nullable expressions. You can use IFNONE(a,0) instead of a.HasValue ? a.Value : 0

Old: Bugs.SUM(TimeSpent).HasValue ? Bugs.SUM(TimeSpent).Value : 0

New: IFNONE(Bugs.SUM(TimeSpent), 0).


Boolean Expressions

Decimal values are now automatically converted to double (nullable double) values in case a double value and a decimal value must be used in one expression. Basically, this means you don’t have to use the phrase Convert.ToDouble(it.Decimal) when working with decimal values. This also works for IFNONE/IIF operators: you can simply write IFNONE(it.NullableDouble, it.NullableDecimal) or IIF(it.NullableDecimal.HasValue, it.NullableDecimal.Value, it.Double).

Old: Convert.ToDouble(TotalPoints.HasValue?TotalPoints.Value:0) / (EndDate-StartDate).TotalDays

New: TotalPoints.HasValue?TotalPoints.Value:0 / (EndDate-StartDate).TotalDays


Nullable Bool:

Nullable bool is now automatically converted to bool (with “false” used for null values). So, if nullable bool is used in a place where bool should be used, it will be converted from it.NullableBool to it.NullableBool == True.

Old: IIF(EntityState.IsFinal == True,0,Effort)

New: IIF(EntityState.IsFinal,0,Effort).

If you have any questions about these changes, please feel free to ask us in the comments section below or contact our support team. Have a good day! 

Categories: Companies

Product SAFeTY

The Agile Management Blog - VersionOne - Tue, 07/26/2016 - 14:30

Product SAFeTY

About seven years ago, I started a deep dive into all things product. I found myself coaching teams that could consistently produce, but not consistently produce the right product. I shifted DevJam coaching to be a blend of product discovery and product delivery. The shift included more time spent learning about all things product from brilliant design thinkers like Alan Cooper, as well as any and all product producers, UX designers and product managers who are passionate about learning more about who they are building for and what these people really need.

In recent years, DevJam has been providing more discovery coaching, often times working with organizations that have adopted the Scaled Agile Framework® (SAFe®). The engagements start in a similar fashion: teams and collections of teams (in trains) are doing better moving forward with cross team delivery, but struggling with cross team discovery. For many of these companies, we are helping them to introduce a product discovery cadence to augment the flow in delivery.

Product Discovery and Continuous Discovery

The idea of a discovery cadence is not new at DevJam, but we have adopted it a bit for use within the SAFe framework. To simply introduce the idea of a discovery cadence, let’s examine the simple (and sub-SAFe model) of one team and one product. As an example, many Scrum teams work hard at getting work done sooner. These teams tend to adopt the mantra of start by finishing, working to complete fewer things faster, and then adopt the practice called “backlog grooming” so they are more ready for planning. From that point, adding a bit more intent and a few more practices is all that is needed to produce a cadence of discovery.

An intentional discovery cadence is the starter to what we called continuous discovery or continuous product learning. It tends to take place upstream from delivery but not in a waterfall fashion. For teams that are new to product discovery, working one iteration ahead of delivery is a nice starting place and trying to stay two iterations ahead with readiness is the next step. For some teams, discovery and delivery are happening within iterations, with discovery feeding delivery and delivery validating and informing discovery thinking around product, services, and customers, or consumers.

One Team, Two Cadences

Getting started can be as simple as a few people from a team, gathering for a handful of sessions where they talk about readiness for the next iteration. To avoid the common pitfall of creating a discover teams and a delivery team, we introduce the ideas of one team, two cadences at the team level, and one community, two cadences at the cross team, program level. For those in the discovery cadence, we start introducing ideas and practices that help them “learn outside the code.”  The following are examples of common discovery practices that augment product exploration and diminish the injection of needless complexity in the delivery space, the code, and the delay environments:

  • Customer development with pragmatic personas and user interviews
  • Product exploration with story mapping, examples, and customer journeys
  • Early learning with A/B testing, prototypes, and other interactive experiments

Cross Cutting Discovery

For more complex, cross team eco-systems, as is the case with many SAFe implementations, we have introduced a cross cutting discovery cadence composed of technical and product people from teams and trains. Starting in a lightweight manner, we introduce short collaborative, cross cutting discovery sessions to help with readiness for work injected within and across teams, as well as within and across trains.

By ensuring that we keep the meeting overhead low, and the collaborative value high, we coach people toward discovery that cuts across teams, leaving the inter-team solutions to the teams. For many clients using SAFe, introducing a cross-team discovery cadence and a collection of tools and practices that help them learn outside the code has improved readiness for planning and decreased the amount of technology needed to produce the same amount of product learning and real value produced.

More information about product discovery and scaling product learning can be found at

Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.

The post Product SAFeTY appeared first on The Agile Management Blog.

Categories: Companies

Why Scaling Agile Does Not Work

Scrum Expert - Tue, 07/26/2016 - 14:00
There are now several frameworks designed for scaling agile. This talk explains the flaws in such frameworks, why they so often fail to produce the desired effects, and what we should do instead. It also addresses some common organizational obstacles to moving fast at scale: governance, budgeting, and the project paradigm – and discusses how to address them. Warning: this talk includes liberal use of real, statistically sound data. Video producer:
Categories: Communities

Manifesto voor Agile Veranderen

Ben Linders - Tue, 07/26/2016 - 10:47

Manifesto Agile Veranderen Ben LindersHet manifesto voor agile veranderen helpt organisaties om hun agility te verhogen. Het zorgt voor blijvende verbetering van de resultaten, tevreden klanten, en blije medewerkers. Dit eerste artikel over Agile Veranderen beschijft de uitgangspunten en waarden met behulp van het manifesto voor agile veranderen.

Agile software ontwikkeling is gebaseerd op het Manifesto voor Agile Software Ontwikkeling. Dit manifesto bevat vier waarden en twaalf principes. Het manifesto voor agile veranderen is op een zelfde manier opgebouwd. Het beschrijft mijn visie en werkwijze in organisatieverandering, samengevat in vier waarden. Mijn verander “waarden”


Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Dit zijn de waarden van mijn Manifesto voor Agile Veranderen:

  • Betrekken van professionals en ruimte geven voor ideeën over standaardisatie en voorschrijven van werkprocessen
  • Stapsgewijze evolutionaire verbetering van binnen uit over top down opleggen van veranderingen.
  • Resultaatgericht en intensief samenwerken over directieve doelen met “command & control” management.
  • Prioritiseren en flexibel inspelen op kansen over budgetteren en veranderplannen uitvoeren.

De waarden aan de rechterkant van bovenstaande statements zijn en blijven belangrijk, maar ik geef graag meer aandacht aan de waarden aan de linkerkant. Daarom geef ik bijvoorbeeld de voorkeur aan het in kaart brengen van de bestaande werkprocessen met de medewerkers en samen werken aan verbetering mbv retrospectives in plaats van organisatiebreede uitrol van Scrum met standaard trainingen. En werk ik liever met een veranderbacklog waarin de prioriteiten eenvoudig aan te passen zijn dan met een plan. Ook veranderen veranderd

Anders dan het Agile Manifesto wat al 15 jaar hetzelfde is verwacht ik dat dit manifesto wel zal veranderen. De eerste evolutie is al te zien als je het vergelijkt met het verander manifesto van veranderproject, een samenwerkingsverband van enkele jaren geleden. Bijvoorbeeld woorden als “verbinden” zijn verder uitgewerkt in “resultaatgericht en intensief samenwerken” en het manifesto voor agile veranderen benoemd de rol van de professional en een bottom up aanpak voor verandering.

In de nabije toekomst zal ik diverse artikelen publiceren waarin ik dieper in ga op de waarden van dit manifesto. Ik geef daarin o.a. voorbeelden van betrekken van professionals in verandertrajecten, top-down versus bottom up veranderen, evolutionaire versus revolutionaire verandering en resultaatgericht veranderen.

Categories: Blogs

What’s New in Axosoft Version 16.4?

About SCRUM - Hamid Shojaee Axosoft - Mon, 07/25/2016 - 23:32

Welcome to the newest Axosoft release! Let’s jump into what’s new and beneficial in version 16.4—especially for newer users.


A new in-app tutorial will automatically be triggered when you log in for the very first time.

However, if you’ve already been using Axosoft and want to go through the tutorials as a refresher, simply navigate to: Help In-app Tutorial Show Tutorial Bar

The tutorial bar will appear at the top of the interface and let you choose which tutorials you wish to start.

Screen Shot 2016-07-21 at 8.51.12 AM-2 If you need a refresher on other features of Axosoft, you can always turn on the in-app tutorials.

You can complete each tutorial in whatever order you prefer, and the bar will track your progress. Once you have a good grasp on how to successfully use Axosoft to meet your team’s needs, you can simply dismiss the bar.

Don’t forget, if you need additional resources, you can always visit the Help menu.

Screen Shot 2016-07-21 at 8.54.04 AM-2 Help resources are just a click away. More Updates!

Notifications: They will now include details on what a field was changed from, along with what it was changed to. In order to see this display, be sure you have the {ITEMDETAILS} placeholder set.

Notifications update_crop Notifications now include “Changed From” and “Changed To” info.

Seeing New Items: In List View, there is a new column that shows the number of related items. If you dock the related items pane to the bottom of your screen, you can also include a Work Item Type column.

Combo Search Box: The releases and projects fields have been updated with a combo search box. All options will be listed, but you can quickly refine the list to find what you’re looking for by typing the first few letters of the name of your release or project folder.

New User Token: When creating filters, you can now add a new user token for the Assigned To field called Current User Teams. It will filter items that are assigned to any teams the user currently belongs to.

More Quality of Life Improvements:

  • Hovering over a title that is cut off will show the full title.
  • Search results will now highlight and bold matching strings.
  • You can now remove a subitem from its parent when you view a subitem.

Find out more about this release by watching our newest video.

Categories: Companies

Targetprocess v.3.9.0: TP2 removal, minor improvements

TargetProcess - Edge of Chaos Blog - Sat, 07/23/2016 - 12:59
TP2 removal

As we described in our Phasing out Targetprocess v.2 blog post, we've stopped supporting Targetprocess v.2. This means you'll no longer have access to features which were exclusive to v.2. Only Custom reports, Time sheets, and Global Settings will be preserved. However, all of your data should still be available in Targetprocess 3.

If you have any questions about this change, please contact us.

  • Improved board performance
  • Quick Add buttons are now always visible in List mode
Fixed Bugs:
  • Fixed Feedback popup that appeared too often
  • Fixed a problem where Custom Rule ‘Close a User Story when all its Tasks are done’ only took the first 25 tasks into consideration
  • Fixed issue with displayed password in Git plugin log when timeout occurs
  • Fixed high CPU usage by Cache context
  • Fixed units in List that were incorrectly displayed as sortable
  • Fixed Search icon alignment in Safari
  • Fixed CKeditor table alignment
  • Fixed filter font size in Lookup bubble
Categories: Companies

Minimum Valuable Problem

Tyner Blain - Scott Sehlhorst - Fri, 07/22/2016 - 13:38

redacted use case dependency thumbnail

Defining and building a good minimum viable product is much harder than it sounds.  Finding that “one thing” you can do, which people want, is really about a lot more than picking one thing.  It is a combination of solving the minimum valuable problem and all of the other things that go with it.  Solving for both the outside-in needs and the inside-out goals is critical.

Starting with Icebergs

image of iceberg showing the massive hidden parts

Rich Mironov’s great article, the DIY Illusion, talks about the importance of focusing your team on building what is important to build (and not building something more easily acquired in other ways).  Imagine your team is building a mobile app.  Now imagine your team is building – from scratch – a CRM system to allow you to track all of the users who install the app.  Or imagine they are building a ticketing system – from scratch – to allow you to track development team progress on feature requests and bug fixes.

context of framing

I introduced the Andy Polaine’s concept of designing in different contexts in an article about roadmaps and feature-lists last year.  The same pattern / concept applies here.

Rich’s article describes a micro-version of the classic buy, build, partner decision. When it is your team making decisions about dev-ops or other infrastructure that they need, this is exactly what it feels like and looks like.

Pop up to the broader organization-level context, and now it is the classic MBA version – do we build a new product to complete our portfolio?  Or do we partner with someone else to include their product?  Or maybe acquiring that partner (or just the product) makes the most sense.

Both of those decisions are firmly in the inside-out side of thinking about product.  What about the outside-in framing?  Your customers are making  buy, build, partner decisions about your product.  How do you make sure the right answer for them is “buy?”

another iceberg - emphasizing what is hidden

An important point in Rich’s article is that the work you need to do (to roll your own <insert system here>) is much larger than a shallow analysis would lead you to believe.  The same is true about defining a minimum viable product.  You customers will need to solve more than the single problem on which you begin your focus.

Minimum Valuable Problem

I’m going to spend the next couple weeks talking only about minimum valuable problems, and not minimum viable products, as an experiment to see if it accelerates a change in thinking with my team.  [I dropped the term first in a meeting with executives yesterday (as of when I’m typing) explaining that our product is focused on completely addressing the minimum valuable problem, and got some head nods but no direct commentary.]  If you want to know the results, ask in the comments on this post.

In my mind, I remember reading Steve Johnson quoting Saeed Khan as saying that a minimum viable product is, literally, “the least you could do.”  I hope it’s true, I love that quote.  I don’t know if that’s actually where I heard it, but let’s make it quotable, and see if some tweets cause the original author to magically appear.  An MVP is literally the least you could do with your #product.

US quarter featuring the state of Texas

Why make the distinction between product and problem?  Two reasons – one philosophical and one practical.

Philosophical Soapbox

One thing my clients regularly value from me is that I’m joining their team with a “fresh set of eyes” and one thing I bring is an external perspective on what they are doing and plan to do.  It affords me an opportunity to help shift the perspective of the team from inside-out to outside-in.  In other words, being driven by the needs of the market.  At the product-level of context, this usually means being driven by the problems a particular set of users are trying to solve.  Introducing problem as a totem in many conversations helps reinforce and subtly shift conversations over time.  The longer I work with a particular team, the more I see the results of this.

When people talk about the product they are usually talking about “this thing we (will) build.”  That’s not nearly as valuable for me in assuring product-market fit as if people are talking about the problem we are solving.  I’m on a team in the early discovery and definition phases.

We get more value from conversations about why someone will use the product than discussions around how the product will work.  We get more value from conversations around how the product will be used than from discussions around how much it costs to make the product.

Practical Thinking

A huge challenge in communication is one best described by a sketch of Jeff Patton’s from his book User Story Mapping.

three people discovering they don't ACTUALLY agree[for a larger version, buy Jeff’s book].

When people talk about “the product,” in my experience, everyone in the room will happily carry the conversation forward, each referring to “the product” with no one clarifying precisely what they mean.

When people talk about “the problem” we intend the product to be used to help solve, it is common for the conversation to reiterate, refine, or at least reference which problem we’re speaking about.

I don’t know why these play out in different ways, but they seem to do so.  Perhaps we’ve got a cognitive psychologist in the audience who can shed some light?

Regardless, the minimum valuable problem seems to be something people are comfortable clarifying in conversation.

Solving the Problem

I get to stand on the shoulders of another giant, Gojko Adzic, and his book, Impact Mapping, as my personal product management  jiu jitsu.  Gojko’s approach helps me very quickly define what it means to my user to solve his or her problem.

By focusing on the outcomes (there are, in fact, many ways to get to this – I just happen to find Gojko’s to be compelling), you discover that solving the problem you originally intended to solve may not be sufficient.

Your minimum viable product may be solving half of a problem.  Solving half of a problem is creating half of a product.  There may be cases where this makes sense – splitting stories, incremental delivery, etc.  But it doesn’t make sense for very long.

How often are you interested in purchasing half a solution to a problem you’re facing?  When the brake lights on your car go out, would you ask the mechanic to just fix one of them right now, and schedule a follow-up visit next month to repair the other one?

Defining the minimum valuable problem is defining the minimum viable product.

The minimum valuable problem is one you completely solve.  You may only solve it in a very narrow context or scope.  You may only solve it for a small group of users or a subset of your ultimate market.  You may only solve it adequately, without creating a truly competitive solution.  But for that one customer, in that one situation, you have completely solved it.

Remember – you grow revenue one customer at a time.  This sounds like a platitude, but reverse the perspective.  That one customer is considering multiple vendors for that one sale.  Will the customer pick the vendor who is mediocre (and also mediocre for other customers), or will the customer pick the vendor who is perfect for them (even if imperfect for other customers)?

The Problems Behind the Problem

dependency map of user stories[larger]

The above diagram is a real view of the dependencies of an ecosystem for a product.  It is blurred out because it is real.  What it shows, in the upper left corner is the “target problem” to be solved.  This target is a candidate for minimum valuable problem.

Each connection in red says “requires” because for a given user to solve the problem in their blurred out box requires assistance from another user.  That other user then has to solve the problem of “help the first user.”  Or it could be that there is an operational context like “monitor performance of the [first user group] solving their problem, so we can fine tune the solution.”  When you’re doing service work, or designing whole-products, you see (or should see) this on every engagement.

In the ecosystem of a complex problem-space, we discover that there are multiple parties associated with adequately solving the user’s problem.  Each different color of user reflects a different user involved in the solution of the focus problem for the focus user.  This web of interdependent problems is the rest of the iceberg.

onion diagram

An onion diagram for this same problem space allows us to also very quickly see (even with this redacted version) that there are three systems (or system interfaces) through which different users directly or indirectly use our product to solve their problems.

Bridging the Process Gap

These views of the problem space help us assure that we are solving a valuable problem – which is my preferred definition of a viable product.  As a bonus, they help bridge the gap between the abstract thinking of a product management team and the concrete thinking of the engineering team who will create the solution and the executive team who wants to “know what it is.”

Categories: Blogs

5 Tech Life Hacks You Didn’t Know You Needed

About SCRUM - Hamid Shojaee Axosoft - Thu, 07/21/2016 - 18:59

Life can be tough, we all know this. But, when you know some good workarounds to life’s irritating problems, it can get a little easier. Check out 5 ways our own techies at Axosoft make life just a little happier and a tad easier to navigate.

1. VPN Like a Boss

Jay Pearlman, IT

“My wife and I traveled to New Zealand in the middle of the most recent season of HBO’s Game of Thrones; we just couldn’t miss it and risk falling behind. Unfortunately, you cannot get HBO Go in New Zealand—it’s blocked for some reason. So after doing some research to try to figure out how we could legally watch the episode in some way, my wife said jokingly, “too bad we can’t dig a tunnel to our house from New Zealand to watch the show.” That triggered an idea.

Because I’m an IT guy, I know how to set up VPNs (Virtual Private Networks). I make tunnels through the internet all the time to securely connect servers across the country. So, I set up a VPN tunnel directly to our house. We were able to log in, and load up HBO just like we were sitting in our living room. We ended up watching Game of Thrones on our laptop in a New Zealand hotel room as it aired. There was no worrying about spoilers on Facebook that night. We slept pretty well knowing how the King of the North was handling everything.” 

Jay Perlman Jay Pearlman: setting up VPNs and traveling the world. 2.  Just Google It

Jose Garcia, Developer

“I still don’t think my mom completely understands what Netflix is, so I end up troubleshooting a lot of technical or computer issues at the house. When I do this, I look like a genius. Because of my background, I feel comfortable troubleshooting any device, and I never have to ask someone or pay money to have it fixed unless I need to purchase a new part. Honestly, I think that most people just don’t even know where to start if something technical goes wrong, and they don’t want to break it. I’ve found that if there’s an issue I don’t know how to fix right away, I just Google it. Typically using very specific terms about the issue can take you to a site where someone has figured out how to fix it.”

Jose Garcia Jose Garcia: finding information and taking charge. 3. Use the Inspect Element

Ashley Mayberry, Developer

“If I wasn’t a programmer, I wouldn’t know about this. Simply right click on any web page and choose ‘inspect element’ in any browser. You can do math equations on the fly when you are browsing websites. You can also hack games or view your password and change it to show the text. If there is a button broken and you can’t click on it for some reason, the inspect element enables you to fix a javascript issue or error. In addition, you can change the font size or style if you can’t read it. You can also quickly mock up how sites would look if you changed something.”

ashley01 Ashley Mayberry: Examining code like a detective. 4. Gift Hacks

Brett Goldman, Head of Partners and Integrations

“My favorite isn’t really a tech hack, but a gift hack for my wife. I wanted to make a really nice music box that could play any song and be reprogrammable. I also wanted to have a choice of which box to use because music boxes are often too small and impractical. So, I decided to get a handmade jewelry box from Etsy, modify it and turn it into a music box which plays MP3. I started looking online for a tutorial, but I couldn’t find any instances of someone doing this without destroying the box in any way.

So, I got a battery operated MP3 player with a speaker. I then just replaced the switch with a self-action switch so it’s triggered to turn on when the box is opened. In order to do this, I took a plastic knife that matched the color of the player and put a rubber band around it so when I closed the box it was the height that was needed. I then super glued it into place.

I soldered the MP3 player and the snap-action lever together, then took the plastic knife and hot glued those 2 together. It became this self-contained piece so that if the novelty wears off, you can change it up. And you can switch the songs up too! I only put one song on it, but you can add more. The song I chose? Marry Me by Train.” Awww…

Brett01 Brett Goldman: charming his wife and making things. 5. Never Tangled EarBuds

Shane Rymer, Creative Director

Shane gives credit for this hack to The Verge, but adds his own “twist.”


Categories: Companies

Making Release Frictionless, a Business Decision, Part 2

Johanna Rothman - Thu, 07/21/2016 - 17:23

In Part 1, I talked about small stories/chunks of work, checking in all the time so you could build often and see progress. That assumes you know what done means. Project “done” means release criteria. Here are some stories about how I started using release criteria.

Back in the 70s, I worked in a small development group. We had 5 or 6 people, depending on the time of year. We worked alone on our parts of the system. We all integrated into one instrument, but we worked primarily alone. This is back in the days of microcomputers. I wrote assembler, Fortran, or microcode, depending on the part of the system. I still worked on small chunks, “checked in,” as in I made sure I saved my files. No, we had no real version control then.

We had a major release in about 1979 or something like that. I’d been there about 15 months by then. Our customers called the President of the company, complaining about the software. Yes, it was that bad.

Why was it that bad? We had thought we were working towards one goal. Our customers wanted a different goal. If I remember correctly, these were some of the problems (that was a long time ago. I might have forgotten some details.):

  • We did not have a unified approach to how the system asked for information. There was no GUI, but the command line was not consistent.
  • Parts of the system were quite buggy. The calculations were correct, but the information presentation was slow, in the wrong place, or didn’t make sense. Our customers had a difficult time using the system.
  • Some parts of the system were quite slow. Not the instrument, but how the instrument showed the data.
  • The parts didn’t fit together. No one had the responsibility of making sure that the system looked like one system. We all integrated our own parts. No one looked at the whole.

Oops. My boss told us we needed to fix it. I asked the question, “How will we know we are done?” He responded, “When the customers stop calling.” I said, “No, we’re not going to keep shipping more tape to people. What are all the things you want us to do?” He said, “You guys are the software people. You decide.”

I asked my colleagues if it was okay if I developed draft release criteria, so we would know that the release was done. They agreed. I developed them in the next half day, wrote a memo and asked people for a meeting to see if they agreed. (This is in the days before email.)

We met and we changed my strawman criteria to something we could all agree on. We now knew what we had to do. I showed the criteria to my boss. He agreed with them. We worked to the release criteria, sent out a new tape (before the days of disks or CDs!) to all our customers and that project finally finished.

I used the idea of release criteria on every single project since. For me, it’s a powerful idea, to know what done means for the project.

I wrote a release criteria article (see the release criteria search for my release criteria writing) and explained it more in Manage It! Your Guide to Modern, Pragmatic Project Management.

In the 80s, I used it for a project where we did custom machine vision implementations. If I hadn’t, the customer would have continued asking for more features. The customer did anyway, but we could ask for more money every time we changed the release criteria to add more features.

I use release criteria and milestone criteria for any projects and programs longer than three months in duration, so we could see our progress (or lack thereof) earlier, rather than later. To be honest, even if we think the project is only a couple of months, I always ask, “Do we know what done means for this project?” For small projects, I want to make sure we finish and don’t add more to the project. For programs, I want to make sure we all know where we are headed, so we get there.

Here’s how small chunks of work, checking in every day, and release criteria all work together:

  1. Release criteria tell you what done means for the project. Once you know, you can develop scenarios for checking on your “doneness” as often as you like. I like automated tests that we can run with each build. The tests tell us if we are getting closer or farther away from what we want out of our release.
  2. When you work in small chunks, check them in every day and build at least as often as every day, you can check on the build progress. You know if the build is good or not.
  3. If you add the idea of scenarios for testing as you proceed, release becomes a business decision,  not a “hardening sprint” or some such.

Here’s a little list that might help you achieve friction-less releases:

  1. What do you need to do to make your stories small? If they are not one day, can you pair, swarm, or mob to finish one story in one day? What would you have to change to do so?
  2. If you have curlicue stories, what can you do to make your stories look like the straight line through the architecture?
  3. What can you do to check in all the time? Is it a personal thing you can do, or do you need to ask  your entire team to check in all the time? I don’t know how to really succeed at agile without continuous integration. What prevents you from integrating all the time? (Hint, it might be your story size.)
  4. Do you know what done means for this release (interim and project)? Do you have deliverable-based planning to achieve those releases?

Solve these problems and you may find frictionless release possible.

When you make releasing externally a business decision—because you can release internally any time you want—you will find your project proceeds more smoothly, regardless of whether you are agile.

Reminder: If you want to learn how to  make your stories smaller or solve some of the problems of non-frictionless releases, join my Practical Product Owner workshop, starting August 23, 2016. You’ll practice on your projects, so you can see maximum business value from the workshop.

Categories: Blogs

Making Release Frictionless, a Business Decision, Part 1

Johanna Rothman - Thu, 07/21/2016 - 16:40

Would you like to release your product at any time? I like it when releases are a business decision, not a result of blood, sweat, and tears. It’s possible, and it might not be easy for you. Here are some stories that showed you how I did it, long ago and more recently.

Story 1: Many years ago, I was a developer on a moderately complex system. There were three of us working together. We used RCS (yes, it was in the ’80s or something like that). I hated that system. Maybe it was our installation of it. I don’t know. All I  know is that it was too easy to lock each other out, and not be able to do a darn thing. My approach was to make sure I could check in my work in as few files as possible (Single Responsibility Principle, although I didn’t know it at the time), and to work on small chunks.

I checked in every day at least before I went to lunch, once in the middle of the afternoon, and before I left for the day. I did not do test-first development, and I didn’t check my tests in at the time. It took me a while to learn that lesson. I only checked in working code—at least, it worked on my machine.

We built almost every day. (No, we hadn’t learned that lesson either.) We could release at least once a week, closer to twice a week.  Not friction-less, but close enough for our needs.

Story 2: I learned some lessons, and a few years later, I had graduated to SCCS. I still didn’t like it. Merging was not possible for us, so we each worked on our own small stuff. I still worked on small chunks and checked in at least three times a day. This time, I was smarter, and checked in my tests as I wrote code. I still wrote code first and tests second. However, I worked in really small chunks (small functions and the tests that went with them) and checked them in as a unit. The only time I didn’t do that is if it was lunch or the end of the day. If I was done with code but not tests, I checked in anyway. (No, I was not perfect.) We all had a policy of checking in all our code every day. That way, someone else could take over if one of us got sick.

Each of us did the same thing. This time, we built whenever we wanted a new system. Often, it was a couple of times a day. We told each other, “Don’t go there. That part’s not done, but it shouldn’t break anything.” We had internal releases at least once a day. We released as a demo once a week to our manager.

After that, I worked at a couple of places with home-grown version control systems that look a lot like subversion does now. That was in the later 80s. I became a project manager and program manager.

Story 3: I was a program manager for a 9-team software program. We’d had trouble in the past getting to the point where we could release. I asked teams to do these things: Work towards a program-wide deliverable (release) every month, and use continuous integration. I said, “I want you to check everything in every day and make sure we always have a working build. I want to be able to see the build work every morning when I arrive.” Seven teams said yes. Two teams said no. I explained to the teams they could work in any way they wanted, as long as they could integrate within 24 hours of seeing everyone else’s code. “No problem, JR. We know what we’re doing.”

Well, those two teams didn’t deliver their parts at the first month milestone. They were pissed when I explained they could not work on any more features until they integrated what they had. Until they had everything working, no new features. (I was pissed, too.)

It took them almost three weeks to integrate their four weeks of work. They finally asked for help and a couple of other guys worked with the teams to untangle their code and check everything in.

I learned the value of continuous integration early. Mostly because I was way too lazy (forgetful?, not smart enough?) to be able to keep the details of an entire system in my head for an entire project. I know people who can. I cannot. I used to think it was one of my failings. I now realize many people only think they can keep all the details. They can’t either.

Here’s the technical part of how I got to frictionless releases:

  1. Make the thing you work on small. If you use stories, make the story a one-day or smaller story. I don’t care if the entire team works on it or one person works on it (well, I do care, and that’s a topic for another post), but being able to finish something of value in one day means you can descend into it. You finish it. You come up for air/more work and descend again. You don’t have to remember a ton of stuff related but not directly a part of this feature.
  2. Use continuous integration. Check in all the time. Now that I write books using subversion, I check in whenever I have either several paras/one chunk, or it’s been an hour. I check that the book builds and I fix problems right away, when the work is fresh in my mind. It’s one of the ways I can write fast and write well. Our version control systems are much more sophisticated than the ones I used in the early days. I’m not sure I buy automated merge. I prefer to keep the stories small and cohesive. (See this post on curlicue features. Avoid those by managing to implement by feature.)
  3. Check in all the associated data. I check in automated tests and test data when I write code. I check in bibliographic references when I write books. If you need something else with your work product, do it at the time you create. If I was a developer now, I would check in all my unit tests when I check in the code. If I was really smart, I might even check in the tests first, to do TDD. (TDD helps people design, not test.) If I was a tester, I would definitely check in all the automated tests as soon as possible. I could then ask the developers to run those tests to make sure they didn’t make a mistake. I could do the hard-to-define and necessary exploratory testing. (Yes, I did this as a tester.)

Frictionless releases are not just technical. You have to know what done means for a release. That’s why I started using release criteria back in the 70s. I’ll write a part 2 about release criteria.

Categories: Blogs

Lean-Agile Straight Talk: The Doctor Is In! With Dr. Tom Grant

NetObjectives - Thu, 07/21/2016 - 15:23
The Doctor Is In! With Dr. Tom Grant The Doctor Is In! is a weekly webinar and podcast that offers listeners the chance to meet and ask questions of Net Objectives consultants and thought-leaders on a variety of topics. In this show, Dr. Tom Grant and Jim Trott discuss the implications of Lean and Agile software development on middle management. Here are some of the issues they cover:  What...

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

Scrum Knowledge Sharing

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