I am a member of a community of thinkers.

I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

I challenge each community in the software industry to:

* reflect and honor the practitioners who make its existence possible;
* provide an excellent experience for its members;
* support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
* exemplify, as a body, the professional and humane behavior of its members;
* engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
* embrace newcomers to the community openly and to celebrate ongoing journeys; and
* thrive on the sustained health of the community and its members through continual reflection and improvement.

I believe that leaders builders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders the community’s builders.

I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.

”A community of thinkers” by Liz Keogh, Eric Willeke and Jean Tabaka is licensed under a Creative Commons Attribution-Share Alike 3.0 License.

Aaron Agile, Lean

So that we can easily find ways to constantly improve while collaborating effectively and sustainably, I like kanban as a tool which shows what constrains transforming concepts into cash. I believe it allows us to see the whole system and our part in what to do to help in the transformation of the system into a better one and our ideas in to innovation. It seems to me there would be greater benefits for all involved.

For software a kanban tool must be highly visible, with a policy to strictly limit work in progress and a policy to only accept work when there’s capacity. To be effective, it requires consensus on these policies from the people involved.

Kanban is a Lean way of saying, “I trust and respect you”.

Aaron Agile, Kanban, Lean

If you track them electronically, some of the process changes, as many APLM tools allow for issue tracking. Hopefully, the intent and result still make sense.

Blocker Board
Always preferring high-touch and visible information radiators to track items, I tend to make a physical blocker board for teams I work with. Why do I call it a “Blocker Board”? It alliterates. I am finding it to be a problem to call it this. Perhaps I should change it to an “Obstacle Catcher”, or something that doesn’t make people think the sky is falling, just that we’re hunting for the system constraint.

Reviewing obstacles
Hopefully the obstacles are being removed quickly, and reviewing all obstacles identified during stand up lets the team verify the ones which have been removed. Having the requestor on the card lets that person verify the obstacle is gone. For the new one’s added, adding the day’s date, lets the team understand how long it took to remove, when verifying with the requestor. This review also gives a moment for people to think if they know (or want to admit to) another obstacle in the team’s way.

Obstacles are non-debatable
Having a working agreement that nobody can debate when someone states the fact they know of an obstacle helps ensure people feel comfortable bringing things up. If it is pushed off as, “not really an obstacle” or, “not an obstacle yet” can be very deflating to someone and cause them to resent mentioning it. Even if the requestor does convince others and writes it up, they may feel apprehensive that it will truly be removed.

Obstacles must be removed immediately
Having another working agreement that everyone should endeavor to get obstacles out of the way immediately, helps the morale of the team. Obviously, this allows the team to be as productive as possible. Removing obstacles immediately builds trust within the team and with management, increasing the camaraderie and expanding the notion of who is on the team. Immediate removal motivates the team, increasing respect by dealing with issues brought forth, without questions asked.

Avoid assigning owners and due-dates
Some obstacles take some time to be removed, even when endeavoring to have them gone by the next day. Assigning owners and due dates is a threatening stance. This is doubly true if obstacles are shot down as really existing when initially mentioned. Assigning one owner, especially at stand up in front of the team, implicit blame is laid on this person for having a problem. The date can only be a guess, and is now given under duress, if it is also in front of everyone. Date assignment allows the person to procrastinate on it, or use it as political leverage. It is stating that the team is fine allowing an obstacle to exist, and slow down the system. For political leverage, it is saying that I will not remove this obstacle, until you do something on my behalf. With the date being a guess, what happens when it comes up and the obstacle is still around? How much are you allowing someone to “game the system”? Assigning owner and due-date erode the sense of team and of collaboration. Avoid this, no matter how much you may feel it is the right thing to do.

If all else fails, prioritize obstacles
When the rate of obstacle removal is less than the rate of obstacle identification, there is yet another obstacle in the way. It might be incredibly difficult to find. In the mean time, prioritizing the ones that are identified helps find the greatest one for the most people. This may be close to, or a symptom of, the system constraint.

Finding the system constraint
Somewhere in the system, there is a very large obstacle, causing a bottleneck that could potentially be jeopardizing success, destroying morale and causing most of the stress. This is the team’s most significant impediment. This constricted area is the system constraint, and is where work passes through at the slowest rate. Having the practice in place of including the date added shows which ones have been around the longest, pointing the way. Agreeing to remove them immediately adds to the significance of obstacles that won’t go away. Prioritizing obstacles will also help identify symptoms of this constraint, and maybe even the constraint itself. Adding the requestor allows the organization to recognize the person who found this constraint, and reward them along with those who removed it, for helping to bring the team to a greater level of performance.

Removing the system constraint
Theory of Constraints explains it thus:

1. Find the system constraint
2. Elevate it (highest priority)
3. Subordinate everything else (nothing is more important)
4. Exploit the constraint (get rid of it for now and forever)
5. See step 1

Eventually, the largest obstacle which cannot be removed is found. Keeping this part of the system on a regular cadence and knowing it cannot go faster, makes it the heartbeat of the organization.

Aaron Agile, Kanban, Lean, Scrum

It’s a rather long list on Amazon.

http://icanhaz.com/AgileForSoftwareDevelopmentOrganizations

Sorted by fundamentals, then technical, some management and enterprise in there, too.

What would you like to see added to it?

Aaron Agile, Lean, List, Scrum

After VYC2.0 launched, I was asked who were the heroes in the group. The one or two people who deserved recognition for all of their hard work. I was hunting around for the email chain, but I’m pretty diligent about deleting emails. I wish sometimes I wasn’t so relentless at that, but I don’t have it. Essentially, I responded that calling out a couple of people creates competition, that everyone stepped up and deserves to be recognized. Management agreed, and everyone involved wound up with a Flip, and I was asked how we may be able to codify some whole team incentive.

My answer was pretty short in coming, as I have wanted to establish the proposed incentive program written about in the ground rules for one team I was working with doing kanban stuff.

The following is what was agreed upon by our senior management. Some things were changed, and quite drastically. For starters, credit will only be given for features/stories completed in one Sprint. When asked my opinion, I suggested this may lead to technical debt. It was also decided to have a showdown at the end of the year, and to recognize the team with the most redeemed tokens. I am afraid this is against the whole-team incentive, and once again fosters competition.

Here it is:

“Video Tokens” rewards

Team collects tokens (1) for every MMF/story that is developed & tested in 1 sprint

Eligibility:

All Video Platform Teams

Selection criteria:

MMF/Story must meet acceptance criteria from Product Owner, must be tested and bug-free

Selection process:

At the end of each Sprint, Scrum Master will review Sprint deliverables and compliance w/ selection criteria. Tokens are awarded to a team.

Timelines:

End of each sprint

Rewards:

Finished features can be collected by the team and redeemed for rewards. Team can decide to either redeem their collected points or wait to accumulate more points for a higher reward

• 10 = Beer and snacks for the next Review & Retrospective
• 25 = Team Lunch
• 50 = Movie passes
• 100 = Day off

ALL tokens collected and/or redeemed are counted annually when team enters into Annual Token Standoff.

Program Facilitator

Scrum Master or Program Manager