Skip to content

Feed aggregator

The Tweets You Missed in April

Sonar - Fri, 05/05/2017 - 14:58

Here are the tweets you likely missed last month!

SonarQube 6.3 released: read the news and see in it screenshots!

— SonarQube (@SonarQube) April 12, 2017

SonarCFamily 4.7 Released: 4 new rules and a dataflow engine supporting precise values for integer literals

— SonarQube (@SonarQube) April 12, 2017

SonarCOBOL 3.4 Released: 8 new rules

— SonarQube (@SonarQube) April 13, 2017

SonarLint for IntelliJ 2.9 shows paths across methods calls that lead to an exception

— SonarLint (@SonarLint) April 6, 2017

SonarLint for Eclipse 3.0 detects tricky issues on Java and JavaScript thanks to an extended dataflow analysis

— SonarLint (@SonarLint) April 18, 2017

Categories: Open Source

Docker containers vulnerability scan with Clair

Xebia Blog - Fri, 05/05/2017 - 12:40

When you work with containers (Docker) you are not only packaging your application but also part of the OS. Therefore it is crucial to know what kind of libraries might be vulnerable in you container. One way to find this information is to use and look at the Docker Hub or security scan. The […]

The post Docker containers vulnerability scan with Clair appeared first on Xebia Blog.

Categories: Companies

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

Counting Batch Processes

Agile Estimator - Fri, 05/05/2017 - 05:13

Counting Batch Processes

It seems like batch processing should have no place in agile development. It conjures up the image of someone sitting at a IBM 026 keypunch machine typing in Job Control Language (JCL) and COBOL II. It is doubtful that any agile team has ever experienced this. In any case, that is not what is being counted here.

Batch processes are non-functional processes that do not cause information to cross the application boundary. A typical example of that would be some type of end of month processing. For example, there might be a program that changes the running totals that are maintained in a file. There might be 12 running totals for the past 12 months. The program might discard the oldest total and move the other totals between the 11 months that remain. Then, a new total might be placed in the 12th bucket. Nothing has crossed the application boundary. The program runs because it is scheduled to run at the end of the month. Likewise, it does not issue any kind of user report. End of day, week, month, etc. are not the only possible batch processes. Programs that load information into files may also be batch processes. This is only the case if they have not been counted as conversion functionality.

Sometimes, it is easier to identify batch processes by describing what they are not. Batch processes are not functional. Therefore, anything that is functional is not counted here. If data is transferred to or from an external application, then it is probably functional unless it is updating a code table. Anything reading screens or generating reports are probably functional. In any case, they are not batch processes. When data in an internal logical file (ILF) is updated as part of an enhancement, it is usually considered conversion functionality. For example, if a new field is added to an ILF to contain someone’s birthday, then part of the project would be the conversion job to fill the birthday fields of existing records. What if there were a one-time job to update birthdays from another source. If the birthday field were not new, then the process would not be conversion. However, many practitioners have counted these one-time jobs as conversions. If so, then they cannot be counted as batch processes.

Not all non-functional processes are batch processes. Anything that is designed to be performance enhancing is not considered to be a batch process. Changes to the data in code tables are non-functional, but they are not batch processes. These processes are covered by other non-functional categories. Any batch processes that have not been counted by one of these other functional or non-functional processes can be considered a batch process.

How do you group batch processes? This is where your JCL experience would be helpful. Batch processing was broken into jobs. Jobs were broken into steps. For estimating purposes, consider the job level. All of the steps that occur for that job would be considered part of the batch process.

When calculating the SNAP points for a batch process, first count up the number of File Types Referenced (FTR). If a batch process must read from a customer file, then the FTR number is one. If multiple steps of the batch process read from different files, then the FTR number is the sum of the unique files. In other words, if two steps read from the customer file, the FTR is still one. If one step reads from the customer file and the next writes to the order file, then the FTR number is two. The number of FTRs is used to establish the complexity, as shown in the table at the top of this post. If there is three or less FTRs, there is low complexity; five to nine FTRs, average complexity; 10 or more means high complexity.

The SNAP count is a function of the complexity and the number of Data Element Types. If the complexity is low, the SNAP count is four times the number of DETs; average, 6 times; high, 10 times. This is a time where the DET count must be arrived at with care. Many times in sizing, the DET count becomes part of a range. For example, when arriving at a function point count for an External Input, any DET count over 15 becomes high complexity. It does not matter whether the count is 16 or 60. The situation is different with the SNAP count for a batch process. If an average complexity batch process works with 16 DETs, the SNAP count is 96; for 60 it would be 360. Therefore, an accurate count or estimate of the DETs is necessary. Many times estimators use the number of fields as a DET count. That is not true. Using the example that was mentioned earlier, suppose that the batch process was updating 12 rolling totals. This is one DET, not 12. The repeating groups are all the same DET. There are some borderline cases. Is the date one DET or 3 (month, day and year)? It depends upon whether the different date components are used differently. The estimator should use their judgement.

Here is our example: if there is an end of month process that discards the oldest running total, shifts each of the 11 running totals down one, and puts a new running total in the last bucket, then it is a batch process. Since it only interacts with a single running total file, its FTR is one and the batch process has low complexity. Since it has low complexity and a single DET, the SNAP count is 4 (4 x 1).

The one question on people’s minds should be, “How can I estimate the number of DETs early in the life cycle?” A better question might be, “Can I identify the batch processes early in the life cycle?” The bad news is that you can not. These are the types of things that are identified in the design phase. Did I get your attention? There is no design phase in an agile development effort. There are no analysts, designers or testers. There is only development being done by developers. Developers are clarifying requirements from the user stories during the iteration where they are being implemented. Developers are designing the simplest solutions that work during each iteration and then refactoring those designs when it makes sense to do so. However, all of this development is done during iterations (sprints). The need for batch processes is usually uncovered during later iterations. It is usually after files have been put into place and the need for maintaining different types of data have been uncovered. The good news is that the batch processes do not impact estimates early in the life cycle as much as later. Early iterations are often dominated by additions to functionality. Later iterations and enhancements may be dominated by changes to non-functional aspects of the system.

There are other reasons to identify batch processes. Suppose there is a sprint where it is anticipated that 5 user stories will be implemented. While working on the stories, the need for some bath processes arises. Implementing those processes will probably result in a story or two not being implemented. This is the result in the expansion of software size, not a drop in velocity. This has to be understood so as not to underestimate velocity on future iterations.

People who are using estimating models like COCOMO II, SEER or SLIM also have to capture the programming language or languages being used to implement the batch process. If there are multiple languages, then they must be apportioned. For example, if 50% of the batch process is written in JavaScript and the other 50% is in Perl, then this should be captured.

Categories: Blogs

How to organize the coolest software conference of the year

Xebia Blog - Thu, 05/04/2017 - 20:32

One of cool things I get to do besides being a consultant is (helping) organizing NG-NL. This is the annual conference in Amsterdam dedicated to the Angular framework. As you might expect, a lot of preparation goes into hosting a conference like that and this blog post is meant to give you a sneak peek […]

The post How to organize the coolest software conference of the year appeared first on Xebia Blog.

Categories: Companies

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

To Mock or Not to Mock: Is That Even a Question?

BigVisible Solutions :: An Agile Company - Thu, 05/04/2017 - 17:00


Mocking is a very popular approach for handling dependencies while unit testing, but it comes at a cost. It is important to recognize these costs, so we can choose (carefully) when the benefits outweigh that cost and when they don’t.

A Quick Overview of Mocking

Mocking is a way to replace a dependency in a unit under test with a stand-in for that dependency. The stand-in allows the unit under test to be tested without invoking the real dependency.


A note on terminology:

It would be more accurate to use the term “test double” instead of “mock”, but somehow “mock” has become the generic term among programmers. Bob Martin has suggested the following relationship among the different kinds of test doubles:


That is, a mock is a spy is a stub is a dummy. A fake is a different kind of thing (it has business behavior). For a more detailed explanation of these different types of test doubles, see

The Costs of Mocking

In my experience, there are 3 reasons to mock sparingly:

  1. Using mocks leads to violations of the DRY principle.
  2. Using mocks makes refactoring harder.
  3. Using mocks can reduce the simplicity of the design.

All of these reasons are interrelated (and, you could argue, are just different ways of saying the same thing), but let’s take them one at a time.

Mocks Can Lead to Violations of the DRY Principle

I first read about the DRY principle in “The Pragmatic Programmer” by Andrew Hunt and Dave Thomas. They state it as: “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” (p. 27).

So, this isn’t just about code duplication – it is about knowledge duplication. When you use a mock you are in violation of this principle because the knowledge of how the components in the system interact is defined in two places: once in the production code and once in the tests. Any change to those interactions has to be made in two places.

Mocks Make Refactoring Harder

In the preface of Martin Fowler’s “Refactoring” book, he defines refactoring as “the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure”. One of the XP practices is “refactor mercilessly”. A fair assumption when practicing merciless refactoring is that unit tests should pass before and after any given refactoring that we do. This is the essence of the red-green-refactor cycle: we only attempt a refactoring when we are in a “green” state, and we expect to still be in a “green” state after the refactoring.

But mocks break this assumption, because with mocks our tests do NOT merely test the “external behavior of the code” but also test the internal workings of the code under test — specifically what other modules are being used and how.

Here’s an example that just happened to me recently. I started out with class A invoking methods on two other classes, B and C.


Then I realized the design could be improved if I structured things this way:


The functionality of A had not changed, as far as its external behavior goes. But in the tests for A, I had mocked out B, so with this refactoring many of the A tests were now broken. Mocking couples the production code to the test code in a way that hinders refactoring, because with mocks your test code knows about the internal workings of the code under test.

Mocking also inhibits refactoring because some refactoring tools do not cleanly refactor code that uses mocks (renaming a method, for example, may not catch method names that are represented as strings, as in some mocking frameworks).

Mocks Reduce Design Simplicity

In Cory Haines’ book “Understanding the Four Rules of Simple Design”, he defines a simple design as “one that is easy to change”. As illustrated in the above example, the use of mocks makes the system harder to change.  When the system is harder to change, we become reluctant to refactor, and the design slowly deteriorates over time.

Arlo Belshee asserts that the need for mocking is a sign of a design with too many dependencies. At a Seattle Software Craftsmanship meetup in May of 2014 he put it this way: Mocking “basically allows me to treat highly dependent code as if it were not dependent, without having to change the design. Perfect for legacy, perfect for learning, a real problem when you are trying to get design feedback. As soon as I remove the [mocking] tool then I am required to change the design and reduce the dependency and reduce the coupling. That’s what all the design literature is about.” (Watch the full talk here.) This is a good description of how mocking reduces the simplicity of the design, namely, by increasing coupling and increasing the cost of change.

When to Mock

So, given these drawbacks to mocks, how do we decide when to use them? I use the following guidelines in my own code:

  • Only use a mock (or test double) “when testing things that cross the dependency inversion boundaries of the system” (per Bob Martin).
  • If I truly need a test double, I go to the highest level in the class hierarchy diagram above that will get the job done. In other words, don’t use a mock if a spy will do. Don’t use a spy if a stub will do, etc. This is because the lower you go in the class hierarchy of test doubles, the more knowledge duplication you are creating. (A test that uses a dummy only knows that a collaborator is used in the code under test. A test that uses a mock knows which method on the collaborator is used, how many times it is invoked, and the types of the parameters that are passed).
  • If I truly need a test double, I prefer to write my own, rather than using a mocking framework. This keeps the code simpler and works fine in most cases. I will resort to using a mocking framework when mocking fairly large interfaces or third party libraries.

Also, as Arlo mentioned above, mocking may be needed initially when getting legacy code under test, until some of the dependencies can be removed.

By using mocks sparingly, we can keep our code DRY, enable easier refactoring, and improve the simplicity of our designs.

The post To Mock or Not to Mock: Is That Even a Question? appeared first on SolutionsIQ.

Categories: Companies

7 Ways to Manage Date-Driven Work in LeanKit

Don't let deadlines blindside you! Avoid last minute scrambles with these seven tips to help you stay on top of date-driven work in LeanKit.

The post 7 Ways to Manage Date-Driven Work in LeanKit appeared first on Blog | LeanKit.

Categories: Companies

Remote – More Info

Growing Agile - Thu, 05/04/2017 - 15:29

These sites are great resources about remote work, go ahead and explore them.

And if the remote bug has bitten – theres even a site to help you find a remote job!

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

Dealing with the Pesky People Parts of Software Development

TV Agile - Wed, 05/03/2017 - 16:21
This talk explores communications between coders, some of the personality challenges and interactions with normal people.From pocket watches to great cathedrals, craftsmen created wonders of the age. While individual skill, repetition and accomplishment was important, communication between the great craftsmen was key. We will explore the use of code reviews (specifically Reviewing for Intent) in […]
Categories: Blogs

Takin’ it to the Streets: Agile Day Atlanta 2017

Leading Agile - Mike Cottmeyer - 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

Bringing Agility and Change Management Together at ACMP 2017

BigVisible Solutions :: An Agile Company - Tue, 05/02/2017 - 17:00


Change management is a crucial part of any Agile transformation, because it focuses on helping individuals transform and change in concert with the organization’s own transformational changes. The Association of Change Management Professionals (ACMP) arose in direct response for the need of guidance and support for change professionals from a formal organization. It’s been six years since ACMP launched the annual Change Management conference and SolutionsIQ is again excited to participate in Change Management 2017, bringing our expertise and experience in Agility to share with this industry. This year, the three-day conference will focus on providing the tools to help change professionals, including Agilists, help their client organizations succeed. SolutionsIQ’s all-access podcast series Agile Amped will be onsite so you won’t miss any of the action! You can expect more “Inspiring Conversations” with thought leaders in the change management industry.

Last year, ACMP celebrated its fifth anniversary running Change Management, and the President Donna Brighton and Vice President Rhiannon Cooke shared their pride with Agile Amped. Watch the podcast now:

Agile and Change Management

We have written and discussed the growing need for change management and Agile to come together, because the increasing complexity of the modern world requires an individual and organizational approach to life and work that necessitates an fully developed ability to change quickly and responsively. Here is a collection of some of our thoughts on the matter of leading Agile change.

Leading Agile Change Webinar

Many change leaders approach Agile adoption with naïve expectations. They don’t understand that training and coaching teams alone won’t be enough to ensure that their Agile initiative succeeds. Agile transformation entails change that will be broadly felt throughout the organization in policies, processes, mindset and culture. The key to successfully leading change that runs this deep is organizational change management. Organizational change management helps change leaders usher in extensive operational and structural changes. Even more important, it helps leaders facilitate the human aspects of change that occur during Agile transformations. In this webinar, we discuss what an Agile transformation is, how to successfully engage stakeholders, the critical role of change management and how to lead Agile change successfully.

Watch Now

In addition to this webinar (our most popular webinar in 2016), SolutionsIQ Solutions Consultant Dan Fuller has written more on the intersection between Agile and change management, in particular how Agile methods and mindsets can complement and help evolve traditional change models like ADKAR and Kotter Accelerate.

ACMP 2016 Podcast Highlights

If you’re on the fence about attending Change Management 2017, here are a couple of podcast highlights that may sway you to go.

CIO Tim Creasey at the Intersection of Agile and Change Management

Email Monday, training Tuesday, change Wednesday – that’s how quickly some people think change happens. Prosci CIO Tim Creasey points out that change management aims to “prepare, equip and support people to be successful in the changes” requested of them, and that process needs time to take effect.

Dean Anderson: “Leaders Either Enable or Block Change”

Being First has focused on designing and leading transformational change for 40 years. CEO Dean Anderson has been watching Agile grow in the past decade or so and has come to recognize its value. Dean says that change management and Agile share similar values and philosophies in “how to drive high performance in individuals, teams and organizations”.


Join Us in New Orleans or Online!

There’s still lots of time for you to sign to attend Change Management 2017 in beautiful New Orleans, Louisiana. Great gumbo! If you can’t make it in person but still want to see what the change management industry has to offer Agilists, subscribe to Agile Amped right here, right now!


The post Bringing Agility and Change Management Together at ACMP 2017 appeared first on SolutionsIQ.

Categories: Companies

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

Book Review:: Agile Noir by Lancer Kind

Agile Complexification Inverter - Tue, 05/02/2017 - 13:53

 Agile Noir by Lancer Kind    and I'm envisioning a 1956 black and white film Kartar is the metaphor of his project.

First, allow me to layout some ground rules and a touch of the backstory...

I'm not a professional book reviewer, nor paid in anyway to read.  But if I could get that gig... I'd be a happy camper.  I've never written a book, but I've hacked out some code, a few articles, some of which might be considered book reviews.  I've worked in the Agile industry for more than a decade (but who's counting), and so - I may be a little close to the topic to have proper literary impartial bias.  In fact let me just go ahead and be explicit - I've done this, been there, got the t-shirt; I shit you not - this shit is for real!

Agile Noir by Lancer Kind
Now the ground rules...  I think this review will be written ... what's the word... while I'm reading, at the same time, without much delay in the reading - writing situ.... iteratively... oh I give up...

So don't be surprised - dear reader - if I just drop off in the middle...
                       ... maybe check back every week until I finish
March 22,
I've studied the cover... quite a nice graphic - to bad the whole novel isn't a graphic novel; oh - maybe it would be too bloody,  I could see Agile Noir becoming a Tarantino film.  As I sat looking at my book to-do stack... I skipped a few levels down the stack and pulled out Lancer Kind's 2016 Agile Noir.  I have read some of his previous comics titled Scrum Noir (vol 1, 2, 3).  So maybe I know what to expect - should be a fun romp in the fast lane with lots of inside the industry puns, innuendo and metaphors.

Well the damn dedication just reeks of an Agile Coach - Servant Leader (puke, barf.... moving on).

The High Cost of Schedule Slip
Now you may not find the situation Kartar finds himself in funny...  allow me to add some overtones of irony....  I'm going to go out on a racist limb and suggest that Kartar is an Indian.  That he is working in the heart of the Indian nation (Los Wages, NV), perhaps on a job for an Italian crime boss.  And none of these circumstances have anything to do with one of the world of science's biggest failures - Columbus's discover of the New World - which the thought was India, and named it's inhabitants there by creating the confusion we will have to deal with evermore.  Now Columbus was of course searching for a way to reduce the schedule required for shipping spices.

Kartar appears to be very emerged in planning and the art/science/pesdo-truth of planning and predicting the future of projects.  And he may be a master with the Gantt chart (which is footnoted on page 18).

This is all ringing just too true ... and I'm envisioning it in the style of a 1956 black and white film...

Kartar is the metaphor of his project... it seems that it's not quite on schedule... he's late to a just announced meeting with some superior and is driving at break neck speed on loose sand in the Vegas out skirts creating over bumps and ditches in his car with the accelerator pinned to the floor - because some people in a van might be trying to kill him.  Happens ALL - THE - TIME.

April 4th
Finished chapter 1.  That Bastard.  He killed off our hero Kartar.  oh - OPPS - SPOILERS!
I truly don't know if I should throw the book in the garbage bin or keep reading... going to bed.

April 6th
OK - that was quite the trick, Chapter 2, Rowing over a better Waterfall is a twist... but now it's getting interesting and our hero is back, yet I fear not quite in control of his project.

April 10th
The chapter Death by Documentation is just that... a death march, I almost quit.  The chapter is worth skipping if you have ever been on one of these classic projects - then you already know enough to thumb to page 89 and restart.  However if your not in IT or project management work of any type (Record Scratch: then how in the heck did you find my blog - and why are you reading this book?) you might enjoy the chapter as it will explain how all of your companies IT project fall behind schedule and never deliver what you want.  Read it - little bells of enlightenment will chime in your head.

The introduction of the IT Mechanic is quite fun.  He's almost a stalker... yeah, he's definitely a PM stalker.  This character is going to be fun.  He's reminding me of someone I've met... and someone from my youthful days of reading Carlos Castaneda.  The character's name is "J" could it stand for Jaun (as in don Jaun Matus)?  He's got an interesting calling card with no numbers or email addresses.  I'd recommend he try Moo - best printing house in the business.  J has some psyc skills and quite a few trick up his sleeves (he is living in the land of Penn & Teller after all).

I really enjoyed this chapter, but then almost any thing would be great after that death slog of documentation hell.

April 12th 
Sprinting is the right word for the next chapter... it's a dash by Usain Bolt.  In Sprinting with a Bollywood Autobot Kartar learns to write user stories and mix drinks of analysis, design, requirement, and development.  He attempts to negotiate on delivery with the owner and in the end crosses the third rail of the PMI tracks in a Lovers quarrel.  Oh - damn, that's not at all what happens.  But it's a lot of fun and went by really fast.  Don't know if we can sustain this pace for the rest of the book.

April 19th
Scrumming in a Waterfall - nice visual, great chapter.  I'm pulling for Kartar, he's doing all the right behaviors, making mistakes and learning each step of the way.  One day he's going to land this project in the success column of management's spreadsheet.  It appears that's how interested the big boss is in the project (affectionally called "Winner").  It's right when Kartar is about got the dirty little secret of Scrum figured out in this iteration that the Lovers, Sis & Lex show up and we cycle under the pressure of the waterfall, tumbling and gasping for air.  

How do you explain water to a fish?  I'm thinking that Kartar is learning all kinds of things in this iteration.  He's gotten lesson at the firing range, upgrade his tiny pistol to an arsenal that Fiona Glenanne (Burn Notice) would be proud of - maybe she'd invite Kartar to show her his car trunk.

But by the end of this chapter - we are back in the rabbit hole with Alice and late, we're late, for an important date.

April 23rd
I've come to understand something about "new new product development" in the software world... it requires great Product Vision and this chapter illustrates a wonderful secret of the process.  This is a wonderful view of the typical company move to the Agile mindset.  Place yourself in Kartar's view and you may believe you have the system figured out.  But is there something missing?  All the teams are scrumming and getting along, produce working software.  It's a happy time on the project.  I'm left wondering what could possibly happen next (hint its not near enough to the end of the book).

April 30th
The next two chapters are great... I couldn't put down the book, had to see Kartar's fate - could he ship the Winner, or would the PMI high priestess Lex & Sis reclaim their underling that has gone astray?  Yes (SPOILERS), of course he get's his team doing Scrum, and the the other's join in the game to ship working software... but what stresses might this cause within this Vegas eco-system?

Well, you may make a guess - but it might surprise you how this project to produce the mobile gambling game-boy turns out.  And if there is a hero... I'm sure it's not Kartar, but he doesn't disappoint.

Addendum ~=  Moral of the Story
The last two chapters, are really addendum, or afterward, for those of you who wish to go beyond the story and understand the underlying moral.

So at this departure point, allow me to confess.  I enjoined this task of reading Agile Noir to answer one personal question:  Would reading a fictional story of a character going through the mental transformation of becoming Agile, be as powerful as a two day workshop that results in a certification, and the beginning of a lifetime's journey to agility, and JOY in the workplace?

This is a difficult question to answer from my current perspective - I would love your (dear reader) answer - it may be much more realistic than my answer.  I believe (I want to believe - me and Muller) that this could be as powerful to a ready open minded person, as an introductory 2 day class.  So my answer to the primary question: YES!

Now one might want to know WHY?
I have an idea why this technique may be just as powerful - maybe better scalability, and in general better ROI.  Come back after this idea bakes a few days...

Table of Contents:
  1. The High Cost of Schedule Slip
  2. Rowing over a better Waterfall
  3. Death by Documentation
  4. The IT Mechanic
  5. Sprinting with a Bollywood Autobot
  6. Scrumming in a Waterfall
  7. Product Vision
  8. Sustainable Pace
  9. Liberation and Libations
  1. Agile Development is about having FUN!
  2. Why Let Your Framework Limit You?

See Also:
Scrum Noir - several volumes of graphic novel about scrum masters and the projects they encounter - also by Lancer Kind
I will have a Double Expresso - Amazon review of Scrum Noir.
Categories: Blogs

Targetprocess v.3.11.2: Undelete Projects and Users

TargetProcess - Edge of Chaos Blog - Tue, 05/02/2017 - 07:59
Restore deleted projects or users

You can now easily "undelete" Projects and Users from the "Deleted items" menu in Settings. Previously, it was not possible to restore deleted Projects and Users without using the API.


Please find more info in the guide.

Visual Reports Improved

We recently made some nice improvements to the Visual Reports Editor. Read about them at this dedicated blogpost.

We really appreciate your feedback on our reports editor. What do you like about it? What could be improved? Let us know what you think at

Fixed Bugs
  • Fixed incorrect effort calculation in Burn Down charts when a Feature is removed
  • Added support for decimal values in custom fields on the Timesheet
  • Fixed: Contributors could not create Releases for Projects that they were not a member of
  • Fixed an exception that would occur when Test Plans and Test Cases on the same Board had different tags
  • Deleted Users will now have a strikeout through their name if someone tries to @mention them in comments
  • Processes are now sorted alphabetically in the Quick Add menu
  • Fixed an exception ('Oops...Something's wrong') that would occur when adding an 'Effort' custom unit to cards in a Person/State view
  • Fixed an inability to delete a Process that is used by deleted Projects
Categories: Companies

Agile Institute has become part of Agile for All

Powers of Two - Rob Myers - Tue, 05/02/2017 - 01:41
Agile Institute (me, essentially) has merged with (joined) Agile for All.  What does this mean for you?Not much will change for you, because not much is changing for me.  All my courses are still available, along with the high levels of personalized service you've enjoyed in the past. I'm still delivering coaching and training in all things Agile/Scrum/XP/Lean, still spending weeks in hotels and airports (and I haven't grown tired of travel yet!), and still working hard to get the book finished.

I have a great deal of autonomy: Agile for All operates a lot like an umbrella organization, or a consortium: They're taking on the paperwork and minutiae that detracted and distracted me from the enjoyment of providing fun and pragmatic Agile courses to my clients. Health insurance, business insurance, quarterly taxes, sending out 1099s, receiving 1099s, reconciling 1099s, the DUNS number, printing & shipping, contracts, subcontracts, invoicing... All done for me for a percentage of my revenues.
Additionally, I have access to hand-picked Agile and Scrum trainers, Executive Coaches, and others whom I can collaborate with in order to best serve our clients.
And, of course, we're all "Agilists," and thus very empirically-minded. If this isn't an improvement for me, for Agile for All, and for my clients (the triple-win!), it's effectively reversible. I retain the rights to my training materials, and the domain will not be lost to me any time in the foreseeable future.
Here are some links for you:
New Agile for All blog:Most importantly to readers of this post, here's my new blog:

I've already posted my first post, which--you may notice--is an updated and improved re-post of a very early post on this blog. I will continue to intersperse the best posts from this older blog alongside new posts, particularly when I'm feeling a little lazy. Like today. ;-)
Existing links that will continue to function:I'm not letting go of this prime Twitter handle:

The Agile Institute Facebook page will remain available for now, as a place for me to easily share interesting posts from others:

My LinkedIn profile has changed, but for other reasons. Here's the new one:
And some exciting new places to stay in touch:Last, but certainly not least, you can monitor the progress of my upcoming book in these two places:

Many thanks for your kind attention and years of readership!


Categories: Blogs

Knowledge Sharing

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