Skip to content

Feed aggregator

Examining the Product Owner Role

Scrum Expert - Wed, 05/10/2017 - 17:20
As with everything else related to agile, the nature of the Product Owner role, and whether it is needed or all, depends a great deal on context. As teams discover this, it leads to some common...

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

Cost of Delay. What Does It Mean?

Leading Agile - Wed, 05/10/2017 - 14:29

Oftentimes when I ask Product Owners how they choose which projects their teams focus on first, they don’t have a technique for prioritization.  Cost of Delay is a concept that a lot of organizations are using and that has gained traction over the years. Unfortunately, many people are still struggling with the concept of Cost of Delay, so I want to put it down in laymen’s terms here in this blog.  Ultimately, the Cost of Delay is a concept that helps you decide—if you have two or more efforts—which order to perform them.

“Cost of Delay” in layman’s terms is the Cost of Delay“Well “Duh” you say … doesn’t really help to define the term using the term itself!  Thanks a lot!” You’re absolutely right, so let’s look at it from a pragmatic vantage point. The cost of delay can mean the loss or deferment of a benefit/value due to the delay and/or incursion of some sort of penalty.

For example:  we have all experienced the “cost of delay” getting out of the house late to go to work.  In Atlanta, a 15-minute delay getting out of the house could result in a 30-minute commute becoming an over-hour nightmare.  Couple being late with the “penalty” implications of missing an important meeting, and you can clearly visualize the “cost of delay”.

In business, we do projects to accrue some expected benefit from the result of that work.  Delay the realization of that project by a quarter, and you’ve incurred a “Cost” of a quarter’s worth of that benefit this fiscal year.

project value over time

Miss an expected market window of opportunity, and the Cost of Delay will include an even greater penalty.

project missed the market window will equal greater cost of delay

In Principles of Product Development Flow, Don Reinertsen speaks extensively about Cost of Delay.   He leverages a model that visualizes projects as rectangles with their vertical axis as the Cost of Delay and their horizontal as the time it takes to implement them.

Leveraging this model enables us to determine which order to do the projects to minimize Cost of Delay.  We can visualize this by plotting the projects on a waterfall diagram as shown below:

minimize cost of delay by accelerating projects early

The first project incurs zero Cost of Delay, because it was begun immediately.  The second project’s Cost of Delay can be visualized as it waits to begin.  Likewise, the third project’s Cost of Delay can be envisioned as it waits for the others to complete.

Therefore, doing the projects in the order on the left diagram incurs less cumulative Cost of Delay than the order indicated on the right diagram.

You don’t want to prioritize your projects to start slowly and accelerate at the end. You want them to ramp up early and taper off to minimize the Cost of Delay.

see your ROI sooner by implementing cost of delay to your project

Think of this in a different way …  What if we plotted value (above) rather than Cost of Delay.  Wouldn’t you rather have 83% of your money in the bank halfway through the time-period vice only 12.5%?

One thing to keep in mind while prioritizing projects is: overall value is not just money.  Nor is all cost paid in dollars.  Certainly, you’re looking for return on investment; however, you also need to consider what will happen to your market share, customer loyalty, and brand integrity as you make tradeoffs to meet or delay deadlines. For example, if you choose to delay a project and your biggest competitor releases their version of your product, what will that do to your market share?  On the flip side, what if you rush to market and release buggy software? How will that impact customer loyalty and, perhaps, overall sales? Will it detract from your brand integrity? These nuances should be saved for another blog post, but I’d be remiss if I didn’t mention some of the less obvious, but ultimately tangible, costs associated with delay.

Remember, too, that the value placed on projects is an expected or anticipated value.  Companies do projects with the hypothesis that they will result in a certain benefit.  What if that hypothesis is incorrect?  Wouldn’t you rather have more time to adjust (so you can hit the overall goal) than less time?!?  How many times have you or your executives bemoaned “I wish we’d known that sooner!!!”   There is certainly a “cost” associated with late feedback!

I hope that this overview of the Cost of Delay is helpful.  For far greater detail, please read Don Reinertsen’s book The Principles of Product Development Flow in which he goes to extensive lengths to describe the Cost of Delay.

The post Cost of Delay. What Does It Mean? appeared first on LeadingAgile.

Categories: Blogs

Visual Project Management: Past and Future

TargetProcess - Edge of Chaos Blog - Tue, 05/09/2017 - 17:33

No matter what kind of project you’re managing, there’s a direct, causal relationship between process and outcome. In other words, it’s not just what you’re working on that matters but how you work on it.

Traditionally, the project management discipline has prized control and long-term forecasting over the particulars of work in progress. But considering 46 percent of all projects still fail to meet their original goals and intent, there’s a growing demand for real-time visibility into the movement of tasks and resources.

Visual project management is a new approach (and new technology) designed to address some of these challenges. By embracing it, teams and organizations can complete projects of any type with greater speed and efficiency.  

What is Visual Project Management?

For the most part, visual PM is exactly what it sounds like: a project management strategy designed to increase success through visualization of project components, such as data and tasks.  Mark Woeppel, the author of Visual Project Management, describes it like this:

“Visual Project Management is a process that uses visualization of the delivery process to drive team behaviors.”

Visual features can be a valuable asset for any project style, but they’re most commonly associated with agile methods such as Scrum and Kanban. In some ways, visual PM takes its cue from the good old-fashioned whiteboard. The whiteboard has served as a roadmap, progress tracker, and collaboration tool for all kinds of development teams.

But the history of visual PM is much older than the whiteboard.

The oldest roots date back to 1896, when Polish economist Karol Adamiecki created the “harmonogram” — a floating bar chart used to show tasks or resources changing across time. Not long after, in 1912, the famous Gantt Chart was born — used first to build ships during WWI and later to construct the Hoover Dam.

Adamiecki’s “harmonogram.”

Adamiecki’s “harmonogram.”

Michael Dubakov, Founder and CEO of Targetprocess, says that visual PM started to crystalize around 2010 with the popularity of the Kanban approach. “One of the Kanban principles is to visualize workflow in order to better understand what is going on and what can be improved.”

Modern visual project management software is much more advanced, but its purpose is the same: to provide greater flexibility and improved outcomes through visibility into bottlenecks, tasks interdependencies, progress, and priorities. “In the recent 5 years we have seen a spread of visual tools like Kanban boards, timelines, and integrated BI systems with powerful reporting,” says Dubakov. In all kinds of industries (especially the IT world)  visual project management is now helping teams stay in sync and respond to changing requirements.

In terms of actual methodology, many of the visual tools that have proven useful combine the best aspects of Kanban and lean production with the Scrum foundation that dev teams are used to. Some users have taken to calling this style “Scrum-ban.”

Common visual features include:

  • Real-time dashboards
  • Timelines
  • Graphic reports (Gantt, burndown, etc.)
  • Boards (Kanban)
  • Product Roadmaps
The Changing Landscape

When fully embraced, visual project management can bring some dramatic improvements to the way teams collaborate and work. As modern software continues to evolve, more teams will adopt visual tools to improve their development lifecycles, over time raising the benchmark for an efficient project delivery process.  

Let’s take a look at some of the specific ways visual tools can impact the future of project management. As your organization plans products and strategies for this  year, try to pull some of these ideas into the conversation.

The Ability to Isolate Problem Areas Faster

As your teams work through various projects, there will inevitably be obstacles — things that slow the movement of tasks, stories, or feature requests during a sprint. Without the necessary visibility, it’s difficult for a project manager to troubleshoot delays or recurring problems.

A visual project management solution can make spotting and solving these “blockers” much easier.  You get a real-time picture of where each component of a project rests, so you can quickly identify bottlenecks and trace issues to their source. For example, let’s say you notice that user stories are repeatedly getting “stuck” in the testing phase or re-entering a later sprint due to unsatisfactory completion. By visualizing the workflow, you can isolate the root cause and then communicate with the relevant team members to initiate change.

Better Resource Planning and Allocation

Resource and requirements planning is one of the most crucial components of any project: get it wrong, and you’ll have a project that gets delivered both late and over budget. There’s a little more leeway with agile projects (since work is done in short iterations), but decision-makers still need to stay responsive to changing requirements and be able to shift priorities or reassign team members when necessary.

Feature Planning By Teams

The speed of change  demands fast resource management. The right visual tools can help you tighten your development lifecycle by maximizing your use of resources—both in the planning phase and in continued optimization during the project. A visual resource planning feature, for example, shows where your team members are assigned and what tasks they’re working on. You can also drill down to assess individual skill sets and schedule availability.

More Projects Completed On-Time

One of the first principles of the Agile Manifesto is “. . . early and continuous delivery.” If your goals are built around this principle, it’s important to remove every possible impediment and give developers maximum visibility. Without the right tools, project information gets siloed into email threads, chat conversations, and spreadsheets, and team members have a hard time remembering who’s working on what. Ultimately, this leads to redundant efforts and a longer cycle time.  

Visual PM can speed progress by conveying real-time project information in a way that is easier to access, understand, and share. It also makes it easier for team leaders to track work in progress and remove impediments before they delay the product. A Kanban board — which uses “cards” to move tasks through different stages of the project — is a perfect example of visual workflow optimization.

Personal Kanban Board

The Spread of Project Management Solutions

Finally, the growing popularity of visual features means that project management software itself will become easier to implement and easier to use for all team members. Even smaller companies with limited experience can set up a cloud-based visual PM solution in less than a day. That means small, agile teams can become even more agile without the overhead of a consulting service or an expensive, time-consuming implementation.

With agility at a maximum, project teams can improve the customer experience by running faster iterations with fewer bugs. Thus, visual PM tools create a more sustainable, scalable development model.

There is, of course, room to grow. Dubakov points to a general lack of research in the visual PM field. “To my knowledge, there are no people who understand both domains well enough in order to lead the visual management movement,” he says. In the coming years, we can hope to see additional research and innovation in some of the following areas:

  • Using visual PM tools to aid decision-making
  • Different visual approaches for different sub-domains
  • Visualizations for planning, capacity management, tracking, and forecasting
  • Process management and problem resolution
  • Closer integration between visual PM and business intelligence tools


Visual project management isn’t some radical new approach that turns the discipline upside down. It’s just a set of tools and techniques that reinforce what we already know: people work and manage projects more efficiently when they’re “in the loop,” and when they have a clear picture of how project components move and interconnect.  The best way to represent and share this information in real time is not with a list, or a spreadsheet, or a series of emails, but with a visual.  

Aleks Peterson is the content manager at TechnologyAdvice, a B2B research firm that connects buyers and sellers of business technology.

Categories: Companies

The Agnostic Agile Oath

Scrum Expert - Mon, 05/08/2017 - 17:25
The Agnostic Agile Oath is a movement that aims at recognizing the importance of being agnostic with agility at any level. As it is stated on the web site: “one size does not fit all, one...

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

Agile on the Beach Sold Out for 4th Year Running!

Scrum Expert - Mon, 05/08/2017 - 16:18
Hundreds of global tech gurus will be landing in Cornwall this July as the annual Agile on the Beach conference held in Falmouth sells out for its fourth consecutive year. Organisers of the seventh...

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

Test-First for Quality

NetObjectives - Sun, 05/07/2017 - 22:18
Quality is a pretty open ended term.  Test-first is often thought of as implementation and verification – is the code being written of high quality?.  But there is also quality to the customer – is the right thing being built?   There is also the quality of the culture of the organization developing the software – is collaboration present?  And finally, the quality of the process being used – is...

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

Getting Business Into The Agile Mindset

NetObjectives - Sun, 05/07/2017 - 09:37
I was recently asked “Any recommendations on a book for how a middle manager can drag a business into an Agile mind set against their will?”  The answer is – “you can’t drag business into an Agile mind set against their will.”  In fact, you really can’t drag anyone into an Agile mindset against their will.  I also find it ironic that I hear Agile coaches ask me a similar question, “Any...

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

The Lasso of Truth

Truth is a wonderful concept - but can we really know it?

I'm very excited about the 2017 release of a Wonder Woman movie.  Can't wait - it looks great, I always love the first in a series.  I like the character development, the WHY of the foundational aspects of the character.  From the preview it looks like we will see Princess Diana of Themyscira grow up and the reasons she finds her self in America.  Fascinating...

I learned a bit about the truth of the back story of the back story of ... well the history of the creator of the Wonder Woman myth in of all places... a training course on DiSC by Dr. Abelson.  [Queue the spooky dream sequence music.]

The inventor of the Wonder Woman myth is William Moulton Marston. Wonder Woman made her debut in All Star Comics #8 (December 1941), scripted by Marston.  If you have one in the garage I'll buy it from you.  Apparently, Marston designed Wonder Woman as an allegory for the true leader; the kind of women who should run society.

"Wonder Woman is psychological propaganda for the new type of woman who should, I believe, rule the world."
Marston [6]
In the World War I years (1917),  [at that time they didn't use the ONE designation for some reason - guess they didn't plan on rev-ing the concept, how silly not to thing that humans would improve the concept of World War] Marston was interested in discovering physiological evidence of a person as they deceive - he's though of as one of the father's of the modern lie detector (Polygraph).  When he created his leader epitome, he gave her the power to discern truth via the Lasso of Truth.

Wonder Woman's physical appearance and her bullet bending bracelets were inspired by Olive Byrne, Marston's lover in an open relationship with he and his wife, Elisabeth.

Going back a bit deeper from the Wonder Woman idealized leader, Marston investigated normal people and their emotions. In the late 1920s he developed a theory of human behavior based upon two aspects, environment and reaction to the environment.  This theory produced the classic quadrant model and is known as the DISC Theory which was refined by in 1956 by Walter Clarke into the DISC assessment model.
"Marston viewed people behaving along two axes, with their attention being either passive or active; depending on the individual's perception of his or her environment as either favorable or antagonistic. By placing the axes at right angles, four quadrants form with each describing a behavioral pattern:
  • Dominance produces activity in an antagonistic environment
  • Inducement produces activity in a favorable environment
  • Submission produces passivity in a favorable environment
  • Compliance produces passivity in an antagonistic environment.

Marston posited that there is a masculine notion of freedom that is inherently anarchic and violent and an opposing feminine notion based on "Love Allure" that leads to an ideal state of submission to loving authority."This DISC theory and model were never trademarked or copyrighted - therefor there are quite a few versions and instances of this tool.  Including wonderfully misleading FaceBook questionnaires that should be view with skepticism.  DISC practiced well by a practitioner can be a very useful tool for self discovery.
David is a "High D" - classic Developer profile
See Also:
Psychometric Assessments - a peek inside the person
Multiple Views of the Truth are Perceptions
The Life of the Mind: Hannah Arendt on Thinking vs. Knowing and the Crucial Difference Between Truth and Meaning Brain Pickings
Categories: Blogs

Live from Agile and Beyond: Agility Infusion 101

Leading Agile - Fri, 05/05/2017 - 19:00

Gaining agility is different than “doing agile”, particularly at scale. This session will start with how agility makes a difference for the business and for the teams adopting it. We will look at the business structures that are needed for agility to thrive, how teams are organized and the new measures that will redefine success. With agility, one size does not fit all, but there are proven solutions, and this session will look at success stories as well as the dead-ends every organization wants to avoid.

Agility Infusion 101: Agile & Beyond from LeadingAgile

The post Live from Agile and Beyond: Agility Infusion 101 appeared first on LeadingAgile.

Categories: Blogs

Live from Agile and Beyond: An Executive’s Guide to Leading a Large Scale Agile Transformation.

Leading Agile - Fri, 05/05/2017 - 16:00

Edit: Live Stream was swapped out for a recording since the internet connection at the conference was unstable.

Join us as Mike explores the change management and engagement techniques necessary to make sure you are building meaningful organizational support as you engage the enterprise. He’ll discuss how to build and execute a change management strategy to keep everyone safe and informed throughout the transformation, how to sustain and improve the changes over time, ultimately creating an organizational ecosystem where business agility is part of the fundamental DNA of the company. The goal of this talk is to show you how to systematically and planfully introduce agile into your organization.

The Executives Step-by-Step Guide to Leading a Large-Scale Agile Transformation from LeadingAgile

The post Live from Agile and Beyond: An Executive’s Guide to Leading a Large Scale Agile Transformation. appeared first on LeadingAgile.

Categories: Blogs

Agile France, Paris, France, June 15-16 2017

Scrum Expert - Fri, 05/05/2017 - 11:00
Agile France is a two-day conference focused on Agile and Scrum that takes place in Paris. It presents Agile practices, discusses their limitations and explore new approaches. All the presentations...

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

Gear Up! - A Leadership Transformation Story

Agile Game Development - Thu, 05/04/2017 - 18:00
This is a story about how effective vision for change can be made collaboratively  among leaders.  The practices used are documented in my recently released book (coauthored with Grant Shonkwiler):

Gear Up! Advanced Game Development Practices

By Clinton Keith

I recently visited a studio that had created a new game and was transitioning to live support for it, adding features and content on a regular cadence. They were struggling with establishing roles and process for this transition and although they had strong leadership in place they wanted help coaching the transition.

I spent three days with this remarkable group facilitating practices captured in my new book “Gear Up!”.  The first days consisted of learning about them by speaking with individuals.  As an outside coach, the key is to ask questions that are neutral and result in hearing what is important for them to communicate.  Powerful questions (page 76) provides some useful guidelines for this.  Typical questions asked were:
  • If you could change one thing, what would that be?
  • What things waste your time?
  • What's best about this group?
  • What is a real challenge here for you?
This exposed some divergent and shared opinions about responsibilities, process and where improvements should be made.

On the second day, we convened offsite in a small Remote Meeting Space (page 73).  The first step was to set the stage for the meeting, to establish goals, make a working agreement and air concerns.  Next I asked them to create a Premortem (page 59) that would reveal a set of shared and individual concerns about their game and studio.   These included:

  • A competitor game releasing a similar feature earlier
  • Late changes from the stakeholders
  • Key developers leaving the studio
  • Major quality problems discovered after deployment

They then prioritized those issues by impact and probability using a Risk Matrix (page 63) and began asking the Five Whys (page 94) on the highest priority concerns

Next we took a look at their existing process by creating a flow map using Visualize Your Feature Workflow (page 66).  Since such a flow is rarely mapped graphically, there is often a disconnect among a leads group about how their process works.  As a result, the big benefit of this  exercise was the discussion during mapping.

Following this, we discussed changes to the flow to address two things:

  • How to reduce the time, from concept-to-deployment, of the process flow for new features.
  • What changes might be effective in addressing the root cause failures they identified earlier.

Having created a new process flow map, we discussed roles and responsibilities.  A favorite of mine, similar to a RACI map, is the SRF map (page 70).  A SRF map identified the roles that sign off on, are responsible for or facilitate any activity in the process flow.  Again, the conversation among the leads is the most important part here and the facilitation by a coach can help them converge to agreements about the roles.

The last step was to test the updated process by throwing use case scenarios at it using the Table Challenge (page 28) practice.  These challenges were derived from the premortem and risk assessment practices.

Finally, the team committed with each other to hold retrospectives at a regular cadence and to review their throughput and the SRF map as part of the discussions on improving their product development flow.

As with the other practices in the book, these three days engaged conversation across the entire group creating a shared vision and vocabulary that is essential to implementing lasting and effective change.

Learn more about advanced practices.
Categories: Blogs Now 100x Artsier

About SCRUM - Hamid Shojaee Axosoft - Wed, 05/03/2017 - 18:09

What do you get when you cross a traveling salesman with a Kraken? Art. You get art.

GitKraken v2.5 is now 3x faster than SourceTree, and is 100x artsier. We’ve combined our love for art and technology and launched a brand new version of our website. Turns out we have a lot of digital artists at Axosoft! One of which is Kyle Smith, a GitKraken developer, a master at digital mark-making, and our first featured artist on the website.

GitKraken v2.5 Featured Artwork

Kyle has been an artist since he started doodling in high school. “My default doodle was a single squiggly line that tightly curved around itself, which from a distance just looked like one large shape,” said Kyle.

He reminisces, “When I began programming, I loved the idea of one day reproducing my high school doodles with code.” So, he started to learn about computer generated art in college, and after graduation, Kyle stumbled upon a paper that described exactly what he wanted to do: turn an image into points on a grid (in a way that resembles stipple art), then connect them using a solution to the traveling salesman problem. He implemented the process in JavaScript and created an SVG, which when animated with vivus, made the image appear to be drawn.

*Knock Knock* Enter Traveling Salesman

The traveling salesman problem (TSP) is a well-known problem in which one must find the shortest route between a set of cities, where each city is visited once and only once. “The great thing about an optimal solution to a 2D traveling salesman problem is that the lines are proven to never cross. So, like my early doodles, this gives images the effect of lines tightly curving around themselves,” said Kyle.

However, rather than creating a single path, as the paper describes, he split the image into many paths. Now, when the svg is animated with vivus, multiple paths are drawn at once, creating a more visually interesting animation.
v2.5 featured artwork
Like I said, we have a lot of digital artists at Axosoft, and it got us thinking that we probably have a lot more in our community too. So, we invite you to create a GitKraken-inspired digital art piece that could be featured on Check out our submission guidelines, and get to it!

Categories: Companies

GitKraken v2.5

About SCRUM - Hamid Shojaee Axosoft - Wed, 05/03/2017 - 17:26

While working on improvements for GitKraken v2.4, we noticed that GitKraken was not running as efficiently as we would like, especially on Windows. As many Windows Git client users may know, most Git GUIs run at the speed of a tortoise, while GitKraken runs its race as the hare.

Sadly, we all know how this story goes… Similar to the hare, GitKraken would blaze ahead when performing certain actions and take its time when performing other actions. So, we decided to give GitKraken a bit of a jolt to see what would happen!

the flash

GitKraken’s new found power of super speed kicked in, and the performance improvements were immediately noticeable when checking out a branch:

branch checkout v2.5

That jolt really got GitKraken going—it will no longer take a nap when you request to view the history of a file:

file history v2.5

While experimenting, and benchmarking the improvements GitKraken had made, we noticed that another Mac and Windows Git client (that is most definitely not SourceTree) had made “significant” improvements to its Windows platform. While they were impressed with their results, we really only had one thing to say:

the Flash

For a bit of fun, we decided to benchmark their improvements against our own. And hey, the more the merrier, right? So, we threw the CLI in there too:

windows checkout speeds

That’s right, GitKraken v2.5 is nearly 3 times faster than SourceTree v2.0! And if you’re wondering ‘how can GitKraken be faster than the CLI?!’ The answer is: because GitKraken does not rely on Git tools and because it does all Git operations directly, speeds can be increased through multi-threading and other techniques. Game, set, match!

Be sure to check out our release notes to see the rest of the improvements and bug fixes in v2.5. 

Categories: Companies

Open Allocation Experiment

TargetProcess - Edge of Chaos Blog - Wed, 05/03/2017 - 16:45

In June 2016, we switched most of the people inside our company to open allocation. They have the freedom to start their own initiatives that are aligned with the central goal of providing a better user experience and fixing critical problems in Targetprocess product.

10 months have passed, and we can now analyze the experiment results. In this post I'll share my opinion about the experiment and mix it with the opinions of the people who participated.


Here is the current initiatives Roadmap. A very good thing is that almost all initiatives were implemented on time. It means people respected their commitments and did their best to keep promises. A bad thing is that some of the implemented features were still not deployed to production servers due to huge infrastructure changes caused by the microservices approach. Basically, you can't give a promise to release something when the infrastructure is not ready.


Another trivial observation is a struggle to fit R&D activities into the Initiatives model. If a team doesn't know how to attack the problem, it created "Research initiative", thus we timebox research. Then, when a solution is found, the team starts a usual Initiative with the results.

Overall, we wanted to solve the problem of speedy delivery, and we got mixed results. Yes, most features were implemented on time, but the infrastructure held them back.

Small Lesson #1. People don't like deadlines, but... deadlines work (when you have no problems with infrastructure).

Deadlines lead to cut corners, worse quality, and poorer solutions. In my personal opinion, this is not a huge problem, since you always have to balance quality and time. Estimates are not forced and, overall, teams have enough time to complete features with good quality.

Freedom of choice

Freedom boosted motivation. People were more enthusiastic to fix some old problems and work on things they wanted to improve a long time ago. Here are some feedback quotes:


On its own, the idea is great and summarizes the essence of any modern social science since it gives freedom to choose your work, stimulates an individual's initiative, pro-activity and creative potential


It inspires people to take ownership of our product. A good practice for freedom, responsibility, and trust.


People feel more passionate and responsible about what they build, I guess. We finally have kind of deadlines, that we stick to. We have a clear definition of done for features, with clear deliverables such as product demo, blog post, working piece of software etc. It seems we deliver better quality, faster and more often.


Initiatives force you to focus on a single task. It improves timely delivery, but hurts mutual help. You might think twice to dedicate several hours of your time to help someone from another team. Sometimes it is good, but sometimes it can lead to local optimization. Sure, you will have your feature delivered on time, but from a company level your help may be extremely valuable.

I think this trade-off is OK. If you like to help other people, you can act in the Free Agent role rather than join an initiative. Or, you become more creative and try to teach people quickly instead of doing everything yourself.

Company alignment

This got worse. Ideas are quite diverse and I hoped to have an emergent vision as a result. I don't think it happened though. We indeed fixed several important problems, but some of the top problems are still there, like extremely poor notifications. I defined a wide goal to improve UX and increase NPS, but this goal was too broad and almost all features can be stretched to fit this goal. In my opinion, this lead to a slight feeling that our direction is unknown and the product has no vision.

Small Lesson #2: Define a bold goal for the year and quite narrow goals for the quarters.

And a quote:

The scope we do is driven by someone's desire but not by market demand. Sure, there is a filter which guarantees that useless feature won't pass. But this filter doesn't guarantee that necessary feature will go into development (because nobody would like to take them and HEADs cannot force). Important items can be in a backlog for years.

Initiative Reward

One of the worst decisions we've made is a reward for successful Initiative completion. Teams that complete an Initiative got several Orange Days (which can be converted to Days Off). This immediately downplays the contribution of all people outside Initiatives.


Initiatives violate our core value: trust. A company should trust that their people will do their best to get a job done. Initiatives might give off the impression that "we don't trust you will do great work without a reward, so we give you a bonus that will stimulate you to complete work on time". It is assumed that development speed is low due to lack of deadlines, but in reality, complexity of integration and some external blockers are the cause.


Some one still needs to do the "dirty jobs" and I don't think that it's fair that this work is not rewarded with orange time.

We wanted to stimulate the Initiatives practice with an additional reward, but it was a bad idea. In fact, freedom of choice and regular intrinsic motivation is enough to make great things.

Small Lesson #3: Don't underestimate intrinsic motivation.

Lack of Training

Another mistake we've made is poor guidance. Yes, I wrote about the practice, ran clarification sessions, and answered questions. But after this initial kickstart, I did a poor job of supporting and promoting it.

I should have worked with key people and ran educational session about how to define top problems, how to do UX, how to test results, etc. Self-organization requires good skills and great understanding of the business context. I relied on cheap self-organization, but this doesn't work in the complex environment of a B2B SaaS company.

Huge lesson #4: Adaptive self-organization demands high energy costs.


In general, people liked the idea, but implementation was far from perfect. Can this model replace traditional Product Managers and Product Owners? Yes, it can. However, make sure that you do the following to avoid our mistakes:

  1. 20% of people should be highly experienced, have deep understanding of business context and good understanding of product development practices. If you don't have it, run training programs and maybe in a year people will be ready.
  2. Education should not stop.
  3. Information transparency is extremely important. You should have a process to collect requests from customers using various channels, aggregate their feedback and help people to distill top problems to focus on.
  4. Be careful with bonuses and rewards. By default it is easier to not have them at all.
  5. Implement freedom gradually.

#5 demands clarification. Imagine, you have a completely strict process where people got all assignments from managers. Here is an example of gradual freedom:

Choose own tasks from a story > Choose own stories from a backlog > Choose large features from backlog > Participate in backlog creation > Choose anything you believe is right.

If you jump to complete freedom from the typical Scrum practice of "Choose own stories from a backlog", people will feel frustration. Help them one step at a time.

Will we stick to Initiatives model?

I think we will go one step back and let people choose features from a backlog and participate in backlog creation, running required training programs for product development in parallel. With more experience we will restart the Initiatives practice. It is fun and works quite nice, but we were unprepared for it as a company, and I was unprepared for it as a leader.

Categories: Companies

Product versus Craft

Scrum Expert - Wed, 05/03/2017 - 16:38
This is a talk about how shifting the focus from craft to product has affected my company. Our delivery teams are required everyday to make trade offs between what would the best technical solution...

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

Takin’ it to the Streets: Agile Day Atlanta 2017

Leading Agile - Wed, 05/03/2017 - 16:13

What if—for one day—you could get some of the most brilliant minds in Agile to share their best ideas for solving tough problems facing your business today? That’s what Agile Day Atlanta is all about: getting those minds together, so you can “take it to the streets” in your company.

We’ll kick off with an expert panel of executives who’ve already led the charge in large-scale Agile transformations. Facilitated by our CEO and Founder Mike Cottmeyer, this panel will explore high-level challenges and give you perspective on how to handle tough issues. Have your questions ready.

Next, whether you’re focusing your energy on transformation, metrics to measure progress, or improving the Agile environment, Agile Day Atlanta has a track for you.

If your plans are centered on transformation, pick the Traffic Planning track to boost your efforts. You’ll learn from speakers like:

  • Danny Presten, from Equifax, who will highlight time-and-effort-saving lessons learned in transforming a 100-year-old, Fortune 500 company.
  • Melissa Oberg, from Fiserv, who will discuss the value in creating model transformation teams that can be duplicated throughout a global enterprise.
  • Tonya Mompoint, from CareerBuilder, who will present a case study of how CareerBuilder used a unique Lean approach to scale Agile.

If your transformation is in place but you need smart tools for measuring team health, progress, and results, go for the Traffic Calming track. You’ll get the heads up from speakers like:

  • John Tanner, from LeadingAgile, who will explain how to use goal-oriented measures (GQM) in software organizations.
  • Rob Gordick, from Daugherty, who will teach you about everything from coaching techniques to Agile core values to Lean and Agile approaches (like Scrum, XP, and Kanban) to the healthy psychology necessary for Agile to be successful.
  • Daniel Vacanti and Prateek Singh, from Ultimate Software, will show you new methods for accurately predicting project completion in the real world.

If you’d like to learn about using best practices and avoiding pitfalls, choose the Traffic Patterns track to fine tune your Agile processes. You’ll find out all the nitty gritty from speakers like:

  • Mike Clement, from Greater Sum, who will introduce you to Mob Programming, techniques critical for its success, and irrelevant practices you can toss.
  • Jeremy Kriegel, from BzzAgent, who will divulge the secrets your customers wish you knew and teach you how to construct a repeatable framework for finding and addressing your biggest risks.
  • David Laribee, from Nerd/Noir, who will present about the most productive testing models in use today and illuminate their various nuances from personal experience, real world example, and case study.

This non-profit, volunteer-driven event is sponsored by LeadingAgile, VersionOne, and CareerBuilder. Proceeds will go to the Atlanta chapter of Power My Learning, a national non-profit committed to empowering underprivileged children in their education.

And, when the tracks are done, plan to kick back with us at the VersionOne offices with BBQ, drinks, and live music.

No matter where you’re heading in Agile, this one-day extravaganza (held in lovely Cumming, GA, northeast of Atlanta proper) can help you get there better and faster.

Seats are limited so be sure to sign up soon!



The post Takin’ it to the Streets: Agile Day Atlanta 2017 appeared first on LeadingAgile.

Categories: Blogs

The Story Behind Gear Up!

Agile Game Development - Tue, 05/02/2017 - 19:03

Gear Up launched today! years almost to the day since my first book.   What took so long?  Well, cranking out 250 pages of text, illustrations and doing most of the proofreading on my own took years.  I'm proud of the result, but it was a "check off the bucket list item" thing at the time.

This book was different.  First, let's visit its origin.

Developers always ask me “we’re having problems doing X with methodology Y, what should we do?”. My first answer is always “What have you tried?”.  I ask this because the best solutions usually come from the people doing the work and experimenting with new practices, not following so-called “best practices”.

“Best practices” implies there are none better. Practices will always change as do our players, technology and markets. This leads to experimental practices, where teams explore ways of adapting to change and improving how they work together.

Thinking about that original question, I think of all the experiments I’ve seen developing games, training and coaching at over 100 studios over the last decade.  I thought that if we could share these as a reference, it might spark that sense of experimentation with many developers.  Experimentation is key not only to creating great games, but creating great teams.

I had a GDC workshop coming up, so I decided to make it about such practices.

The "Shonk" and I sporting our
Rugby jerseys at GDCThe effort hit gold when I started asking for other developers to tell their stories.  One such developer was Grant Shonkwiler, a producer I’ve known for years who has worked on dozens of titles at some of the more renowned studios.  Grant started pumping in practices and ideas for the collection faster than I could keep up.  As a result, the workshop evolved to be a collaborative exercise in discussing and sharing advanced practices, or experiments as we liked to call them.

While collecting these practices, we established some criteria for what makes a practice “advanced”:
  • Experimental - Expressed as something we are doing to solve a specific problem. If it doesn’t solve it, we stop doing it. Implemented with the idea that it will be eliminated or someday replaced with something better.
  • Incremental - Not so large that we don’t see the benefit, at least in an iteration or release cycle of a few months. They can be validated quickly
  • Flexible – Not too specific so as to be adaptable to differing needs
  • Collaborative - Not imposed. Demonstrates consideration, and respect. 
  • Radiative - Visible. Creates transparency. There is sometimes an electronic solution, but they are only recommended for distributed teams
Following GDC, our little group grew to dozens and our collection grew to book-sized proportions which led us to publishing them.  As with the practices, the book is an experiment.  We expect the collection to continue growing, which is why it’s on LeanPub for now.  First, we’ll inspect what the industry says about our effort and adapt it from there.

This experience was a joy.  It felt like being on a team again, which I have sorely missed.  Maybe the next book won't take seven years!

If you are interested in learning more about the book, please visit

- Clint

Categories: Blogs

SpiraTeam 5.2 Enables Effective Program Management

Scrum Expert - Tue, 05/02/2017 - 17:31
Inflectra has to announced the release of SpiraTeam 5.2, the latest version of its Agile application lifecycle management (ALM) suite. This new version includes the latest SpiraTest 5.2 for quality...

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

Keeping User Stories on a Card

Scrum Expert - Tue, 05/02/2017 - 15:49
User stories are one of the main format to record user needs in the Agile world. There is however a debate on the amount of information that should be available to the Scrum team before starting the...

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

Scrum Knowledge Sharing

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