Skip to content

Feed aggregator

Blog Series: TDD and Process, Part 4

NetObjectives - Mon, 04/17/2017 - 14:16
Part 4: Redundancy In part 3, we examined how the same specification can be bound to the production system in different ways, producing executable tests that have various levels of granularity and speed, by creating different bindings for different purposes.  We started with the “full stack” binding: Next, we created a different binding that avoided accessing the database at all by mocking...

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

Targetprocess v.3.11.1: add/edit permissions separated, expand all in List views

TargetProcess - Edge of Chaos Blog - Mon, 04/17/2017 - 08:59
'Expand All' in List views

You can now expand and collapse all of the first and second List hierarchy levels. If you hold Ctrl (Cmd) and click '>' then cards from both levels will be expanded. This works for the first two hierarchy levels of a List view and doesn't affect the third level of cards in terms of List setup.

Permissions to create users through the API for non-admins

Previously, only admin users could post Rest API requests to create and delete users. Now, non-admin users with 'add user' / 'delete user' permissions can create/delete users via API calls.

Add and edit permissions separated for user roles

Starting with v.3.11.1, user roles have separate permissions for adding and editing.

screen-shot-2017-04-11-at-3-32-00-pm

Request email notifications settings updated with "Requesters" check-box

You can set up a 'Request' workflow so that requesters get email notifications every time a specific event event occurs.

screen-shot-2017-04-11-at-4-29-23-pm

Visual Encoding improvements

It’s possible to create a predefined set of global Visual Encoding rules that can be applied to all views and all users. To do this, simply select the corresponding checkbox in the Visual Encoding tab and add the global rules that you want applied to every view in the system:

ve-global2

This setting can only be managed by Administrators; other users can see it in read-only mode.

Fixed Bugs
  • Visual studio add-in supports VS2015 now
  • It wasn't possible to delete a test plan if it had test cases that were run already
  • Fixed occasional improper results when searching by ID in a Relations tab
  • Fixed Project-Team assigments for Observer users according to their permissions.
  • Obsolete Tp.v2 option 'Show in lists/enable for filtering' removed from custom fields setup
  • Fixed User Story progress calculation when converting a Task with time records into a User Story
Categories: Companies

Velocity Calculus - The mathematical study of the changing software development effort by a team


In the practice of Scrum many people appear to have their favorite method of calculating the team's velocity. For many, this exercise appears very academic. Yet when you get three people and ask them you will invariability get more answers than you have belly-buttons.


Velocity—the rate of change in the position of an object; a vector quantity, with both magnitude and direction. “Calculus is the mathematical study of change.” — Donald Latorre 
This pamphlet describes the method I use to teach beginning teams this one very important Scrum concept via a photo journal simulation.

Some of the basic reasons many teams are "doing it wrong"... (from my comment on Doc Norton's FB question: Hey social media friends, I am curious to hear about dysfunctions on agile teams related to use of velocity. What have you seen?


  • mgmt not understanding purpose of Velocity empirical measure;
  • teams using some bogus statistical manipulation called an average without the understanding of the constrains that an average is valid within;
  • SM allowing teams to carry over stories and get credit for multiple sprints within one measurement (lack of understanding of empirical);
  • pressure to give "credit" for effort but zero results - culture dynamic viscous feedback loop;
  • lack of understanding of the virtuous cycle that can be built with empirical measurement and understanding of trends;
  • no action to embrace the virtuous benefits of a measure-respond-adapt model (specifically story slicing to appropriate size)
... there's 6 - but saving the best for last:
  • breaking the basic tenants of the scrum estimation model - allow me to expand for those who have already condemned me for violating written (or suggesting unwritten) dogma...
    • a PBL item has a "size" before being Ready (a gate action) for planning;
    • the team adjusts the PBL item size any/ever time they touch the item and learn more about it (like at planning/grooming);
    • each item is sized based on effort/etc. from NOW (or start of sprint - a point in time) to DONE (never on past sunk cost effort);
    • empirical evidence and updated estimates are a good way to plan;
  • therefore carryover stories are resized before being brought into the next sprint - also reprioritized - and crying over spilt milk or lost effort credit is not allowed in baseball (or sprint planning)

Day 1 - Sprint Planning
A simulated sprint plan with four stories is developed. The team forecast they will do 26 points in this sprint.




Day 2
The team really gets to work.




Day 3
Little progress is visible, concern starts to show.


Day 4Do you feel the sprint progress starting to slide out of control?



Day 5About one half of the schedule is spent, but only one story is done.



Day 6The team has started work on all four stories, will this amount of ‘WIP’ come back to hurt them?




Day 7
Although two stories are now done, the time box is quickly expiring.


Day 8
The team is mired in the largest story.



Day 9The output of the sprint is quite fuzzy. What will be done for the demo, what do we do with the partially completed work?


Day 10
The Sprint Demo day. Three stories done (A, B, & D) get demoed to the PO and accepted.



Close the SprintCalculate the Velocity - a simple arithmetic sum.



Story C is resized given its known state and the effort to get it from here to done. 



What is done with the unfinished story? It goes back into the backlog and is ordered and resized.



Backlog grooming (refinement) is done to prepare for the next sprint planning session.





Trophies of accomplishments help motivation and release planning. Yesterday’s weather (pattern) predicts the next sprints velocity.


Sprint 2 Begins with Sprint PlanningDay 1Three stories are selected by the team.  Including the resized (now 8 points) story C.

Day 2
Work begins on yet another sprint.


Day 3
Work progresses on story tasks.


The cycles of days repeats and the next sprint completes.


Close Sprint 2Calculate the Velocity - a simple arithmetic sum.


In an alternative world we may do more complex calculus. But will it lead us to better predictability?

In this alternative world one wishes to receive partial credit for work attempted.  Yet the story was resized based upon the known state and getting it to done.




Simplicity is the ultimate sophistication. — Leonardo di Vinci 
Now let’s move from the empirical world of measurement and into the realm of lies.








Simply graphing the empirical results and using the human eye & mind to predict is more accurate than many peoples math.




Velocity is an optimistic measure. An early objective is to have a predictable team.

Velocity may be a good predictor of release duration. Yet it is always an optimistic predictor.




Variance Graphed: Pessimistic projection (red line) & optimistic projection (green line) of release duration.



While in the realm of fabrication of information — let’s better describe the summary average with it’s variance.








Categories: Blogs

Introducing Axosoft Version 17.1

About SCRUM - Hamid Shojaee Axosoft - Fri, 04/14/2017 - 16:00

Some software releases have big, visual changes that you see the very moment you open the app. Version 17.0 of Axosoft was one of those big ones, with a huge visual overhaul that tidied up the UI, and big improvements to the user experience.

However, version bumps are also often cause for a large amount of development work being applied to complex solutions that are designed to be, at the front end, almost invisible. These feature sets are in place to remove friction, make you notice the app less, and so you can spend less time doing things.

Axosoft version 17.1 is one such release. In this release, not only have we fixed a bunch of smaller issues that some users on previous versions were experiencing, but we’ve continued the tradition of introducing subtle, elegant solutions to “quality of life” issues that have, until now, made certain repeated tasks less efficient than they could have been.

Version 17.1 has several marked interaction improvements that will soon become so commonplace in your day-to-day use of Axosoft, you’ll forget they’re there at all. So, what’s new?

Fuzzy Finding Duplicates Before You Duplicate Them

Collaborating on projects and releases can create duplication. For example, more than one person might create a task that has been discussed communally. In an effort to reduce the likelihood of the same item being created twice, Axosoft now has a fuzzy finder style drop down to show you existing items in your account that match or share similar names to the item name you are typing.

You can still create the new item as you did before, but if you happen to notice an existing item that you’d like to view or edit, simply select it from the drop-down. Cutting down on duplicated items means less confusion across your team.

Renaming Email Accounts

A lot of users have requested the ability to rename email accounts to something a little more friendly than ihatejira4353234@hotmail.com.

As an admin, simply go to Manage Account > Other Settings > Email Accounts. Open the account whose name you wish to change, and in Account Settings, use the Account Name field to edit the name to whatever you want. Simple!

You Literally Come First

When editing the Assigned To field, there’s a fairly good chance you’ll want to assign yourself to that item, so that’s a pretty reasonable default, right? When creating an item in v17.1, you will now appear at the top of the list of users. Typing another name will narrow down the options as before.

Other Improvements Reports

When exporting a report, you can now include a new field: Parent Item. This allows you to see more easily where sub-items sit in your projects.

Email

In your email lists, you can now filter by emails that are auto-reply emails. Simply click the gear icon in the top-right of the email list, and then select Email > Is Auto Reply filter.

You can also now view the size of attachments for an email, so you know just how large they are.

We hope you enjoy using these new features in version 17.1. As always, this release brings a bunch of other improvements and fixes to the app, and you can see the full list in the 17.1 version history.

Categories: Companies

Team Size Matters, Reprise

Johanna Rothman - Thu, 04/13/2017 - 18:47

Several years ago, I wrote a post for a different blog called “Why Team Size Matters.” That post is long gone. I explained that the number of communication paths in the team does not increase linearly as the team size increases;  team communication paths square when the team increases linearly. Here is the calculation where N is the number of people on the team: Communication Paths=(N*N-N)/2. 

  • 4 people, (16-4)/2=6
  • 5 people, (25-5)/2=10
  • 6 people, (36-6)/2=15
  • 7 people, (49-7)/2=21
  • 8 people, (56-8)/2=24
  • 9 people, (81-9)/2=36
  • 10 people (100-10)/2=45

Here’s why the number of communication paths matter: we need to be able to depend on our team members to deliver. Often, that means we need to understand how they work. The more communication paths, the more the team might have trouble understanding who is doing what and when.

When team members pair, swarm, or mob, they have frequent interconnection points. By working together, they reduce the number of necessary communication paths. Maybe you can have a larger team if the team mobs. (I bet you don’t need a larger team then

Categories: Blogs

Multiple Views of Truth are Perceptions

These are a few of the images that resonate with me. For me they are very close to a door of perception. Now I've never done a mescaline trip, so perhaps I've no clue to what a door frame of perception even looks like... but these images are pretty good with a few beers and some colleagues to discuss there deep meaning and what truth is. Would we even know the truth if it walked up and slapped our face?


Translated: "This is not a pipe"

Cover image of book: Godel Escher Bach

This is Truth; while this and that are true
In any article I write that mentions a door of perception - I would be remise if I didn't mention one of my all time favorite poets and musical group - Jim Morrison and the Doors.  Now do you know that the band is named for?


Aldous Huxley's The Doors of Perception
"Huxley concludes that mescaline is not enlightenment or the Beatific vision, but a "gratuitous grace" (a term taken from Thomas Aquinas' Summa Theologica).[50] It is not necessary but helpful, especially so for the intellectual, who can become the victim of words and symbols. Although systematic reasoning is important, direct perception has intrinsic value too. Finally, Huxley maintains that the person who has this experience will be transformed for the better."
See Also:

Godel Escher Bach An Eternal Golden Braid by Douglas Hofstadter
This Is Not a Pipe by Michel Foucault
Art of Rene Magritte
Categories: Blogs

Deprecating the old Help Desk portal

TargetProcess - Edge of Chaos Blog - Tue, 04/11/2017 - 22:21

We released our Help Desk portal back in 2008. It was a great software that allowed external users to submit requests. Years passed, and it became more and more obsolete from both the technical and user perspectives. Rather than wade through technical debt to try and improve it, we released a separate Service Desk application that already has all the functionality of Help Desk, a better UI, and some cool new features such as custom fields and request types.

We probably should have dropped the old Help Desk back in December 2016, when Service Desk was officially out of beta. It's hard to do, since we sort of got attached to it over the years. Nothing lasts forever though, especially in the software business, so it's time to let it go. Apart from the infrastructure costs of hosting both versions of the software, we also have to maintain and update it to keep up with the latest changes in Targetprocess. For example, in our latest release (v.3.11.0) there were some changes to the way user information is stored, and the 'Forgot Password' button stopped working in Help Desk.

We cannot afford to lose focus at this point, so we are freezing the Help Desk and will completely remove it from our On-Demand servers on June 1st, 2017. What does this mean for you? Most likely, nothing new. If you're not using request management, or if you're already using Service Desk, you don't have to do anything. In case you're not sure, here's what Service Desk looks like:

service_desk_plan

If you are still using Help Desk, that means you will have to switch to Service Desk. All you need to do is activate it at Settings -> Service Desk, and all of your requests and projects will automatically transfer over. On-Premises customers can technically continue using the old Help Desk, though we do not see any good reason for it.

We hope you enjoy the new version of the software. If you have any reason you prefer the old one, please let us know.

Farewell, Help Desk. It's time to move on.

Categories: Companies

Why Getting to Done Is So Important

One of tenets of Scrum is the value of getting work done. At the start of a sprint, the team selects some set of product backlog items and takes on the goal of completing them.

A good Scrum team realizes they are better off finishing 5 product backlog items than being half done with 10.

But why?

Faster Feedback

One reason to emphasize getting work to done is that it shortens feedback cycles. When something is done, users can touch it and see it. And they can provide better feedback.

Teams should still seek feedback as early as possible from users, including while developing the functionality. But feedback is easier to provide, more informed, and more reliable when a bit of functionality is finished rather than half done.

Faster Payback

A second reason to emphasize finishing features is because finished features can be sold; unfinished features cannot.

All projects represent an economic investment--time and money are invested in developing functionality.

An organization cannot begin regaining its investment by delivering partially developed features. A product with 10 half-done features can be thought of as inventory sitting on a warehouse floor. That inventory cannot be sold until each feature is complete.

In contrast, a product with 5 finished features is sellable. It can begin earning money back against the investment.

Progress Is Notoriously Hard to Estimate

A third reason for emphasizing getting features all the way to done is because progress is notoriously hard to estimate.

Suppose you ask a developer how far along he or she is. And the developer says “90% done.”

Great, you think, it’s almost done. A week later you return to speak with the same developer. You are now expecting the feature to be done--100% complete. But the developer again informs you that the feature is 90% done.

How can this be?

It’s because the size of the problem has grown. When you first asked, the developer truly was 90% done with what he or she could see of the problem. A week later the developer could see more of the problem, so the size of the work grew. And the developer is again confident in thinking 90% of the work is done.

This leads to what is known as the 90% syndrome: Software projects are 90% done for 90% of their schedules.

Not Started and Done

In agile, we avoid the 90% syndrome by making sure that at the end of each iteration, all work is either:

  • Not started
  • Done

We’re really good at knowing when we haven’t started something. We’re pretty good at knowing when we’re done with something. We’re horrible anywhere in between.

What’s Your Experience?

Have you experienced problems with teams being 90% done? How have you overcome these problems? Please share your thoughts in the comments below.

Categories: Blogs

Reduxifying GitKraken

About SCRUM - Hamid Shojaee Axosoft - Tue, 04/11/2017 - 16:59

GitKraken is a React app. We’ve been using React since version 0.12.2 (in January of 2015) when we migrated from Angular.js. When we started using React, we architected with the flux library from Facebook as our state model and forged ahead into glory. At first, it was good. Much performance. Many code. Wow!

The initial excitement subsided, and the honeymoon was over. We looked back at our strange mess of state and decided to make a move to Redux. It’s fair to say we had problems scaling with Flux.

The GitKraken team is now finishing up the transition from Flux to Redux, and everything is looking really amazing. There are already a lot of benefits that we are seeing from Redux as we write new code for the application.

Redux vs Flux

For those unfamiliar with Redux, but familiar with Flux, you can think of Redux as a stricter implementation of Flux. Instead of multiple stores and a dispatcher to bind all of the stores together, there is one store that holds all of the state in the application.

For those unfamiliar with both libraries, the Flux library is the implementation of the Flux pattern. The Flux pattern is similar to Model View Controller (MVC), but has a strict one-way data flow constraint.

Flux pattern

At each step in the flow, data is limited to only one movement direction. A view can start an action at the request of a user, the action can generate new data and pass it to the dispatcher, the dispatcher dispatches the results of actions to the stores, and the stores can then emit an update to the views.

In the Redux library, we’ve reduced our total store count to one, and thus we don’t need a dispatcher at all. The dispatcher was originally there to manage the order in which we update stores with action results and keep the stores behaving. Instead, we just directly inform the Redux store of an action that has occurred. So we’ve kept the basic premise of the Flux pattern, but shrank the pattern’s flow by combining the dispatcher and the store.

Redux state

Since we only have one store now, my first reaction was that the store would be a monolithic hellspawn of a maintenance issue, but we actually keep some semblance of order by using Redux’s reducer pattern for our separating concerns. The main mechanism for Redux is the reducer pattern; we have one top level reducer, and we can branch substate trees into smaller reducers.

A reducer is a pure function of state and message to state. We take the previous state tree, a message, and apply some transformation of the state to produce a new state tree. The top level reducer has this shape, and any subreducers also have this shape.

The process of reducing utilizes a constraint we place on the Redux state, that it is immutable. When a message is passed into Redux land, the message is passed through a series of these reducers. Those reducers then decide whether or not to perform an update according to the message.

In our case, the reducers decide whether or not to produce a brand new object. To clarify, we update every reference along a path to an updated value, such that we have made no mutations to the previous state tree. When our reducers produce a brand new object, we know that changes happened to that particular substate tree. In fact, we can trace the new object references to the exact set of changes that have taken place between the previous state and the next state.

Benefits of Redux

What makes this transition so nice to work with is that exactly one message changes state at a time in a very consistent and straightforward manner (a → b). It might seem a bit daunting at first to hoist all state of the app into a single state tree, but the benefits are an amazing trade-off.

Things like time travel can be implemented in a trivial fashion (just store the sequence of state updates). Holding all state in an immutable data structure also allows React to, erm, react better! We can utilize referential transparency when the Redux store emits a change. React can perform a check before updating to see if the top level object reference has changed, and it if hasn’t, shortcircuit the entire rendering tree.

Another nice benefit of the pattern we build with Redux comes into play when we organize our view around our Redux state. We build containers which listen to Redux state, and when a state update occurs, those containers retrieve the relevant changes and choose whether or not to react. Those containers pass any state they care about to a presentation layer. These layers are largely stateless view components (components that only receive props).

Ok! Ok. The benefit I’m describing is that the view layer scales horizontally by top level containers, which hold onto a pure render tree. When we want to add more containers, we can do it in a clean manner (a container is responsible for a full view), even though every container talks to the same store. We’ve basically built an architecture that adds one connection per new UI container when scaling. That’s really clean!

That’s not the only place we scale better. The Redux state itself scales per reducer. We can grow the size of the total state by building new reducers with their own substate, but we don’t have to increase the complexity of already written reducers, nor do we have to manage an explicit dispatch order like we did in Flux. There’s only one store, and our reducers run synchronously, producing a new state one message at a time.

Scaling example

So there you have it. We have an architecture that now provides a cleaner scaling experience in GitKraken.

Categories: Companies

TrumpCare in its Infancy January 2017

I'm extremely concerned today for my country and this planet.  It appears that history is repeating.
    January 27th -- International Holocaust Remembrance Day.

President Trump bars refugees and citizens of Muslim nations entry into the U.S.A.

The New York Times
By Bundesarchiv, Bild 183-N0827-318 / CC-BY-SA 3.0, CC BY-SA 3.0 de
Four score and four years ago a dictator brought forth on the European continent an evolving plan to rule the world and subjugate the masses.

Now we are engaged in a great resistance, testing whether our nation, or any nations conceived from the learning of our mothers and fathers and so dedicated to liberty, can long endure.  We are met on a great social square of technologic creation.  We have come to dedicate a portion of our wealth, wisdom, and life to those in history that have offered their lives and wisdom so that we may learn and prosper.  It is altogether fitting and proper that we should do this.

But, in a larger sense, we can not dedicate -- we can not consecrate -- we can not hallow -- this square.  The brave women and men, living and dead, who struggle here, have consecrated it, far above our poor power to add or detract.  The world will little note, nor long remember what we say here, but it can never forget what they did here in the commons.  It is for us the living, rather, to be dedicated here to the unfinished work which they who fought here have thus far so nobly advanced.  It is rather for us to be here dedicated to the great task remaining before us -- that from these honored dead we take increased devotion to that cause for which they gave the last full measure of devotion -- that this nation, ruled by law, shall have a new birth of freedom -- and that government of the people, by the people, for the people, shall not perish from this planet.

-- David A. Koontz, human patriot


President Abraham Lincoln's address, on Thursday, November 19, 1863, to dedicate Soldiers' National Cemetery in Gettysburg, Pennsylvania, four and a half months after the Union armies defeated those of the Confederacy at the Battle of GettysburgFour score and seven years ago our fathers brought forth on this continent, a new nation, conceived in Liberty, and dedicated to the proposition that all men are created equal. Now we are engaged in a great civil war, testing whether that nation, or any nation so conceived and so dedicated, can long endure. We are met on a great battle-field of that war. We have come to dedicate a portion of that field, as a final resting place for those who here gave their lives that that nation might live. It is altogether fitting and proper that we should do this. But, in a larger sense, we can not dedicate—we can not consecrate—we can not hallow—this ground. The brave men, living and dead, who struggled here, have consecrated it, far above our poor power to add or detract. The world will little note, nor long remember what we say here, but it can never forget what they did here. It is for us the living, rather, to be dedicated here to the unfinished work which they who fought here have thus far so nobly advanced. It is rather for us to be here dedicated to the great task remaining before us—that from these honored dead we take increased devotion to that cause for which they gave the last full measure of devotion—that we here highly resolve that these dead shall not have died in vain—that this nation, under God, shall have a new birth of freedom—and that government of the people, by the people, for the people, shall not perish from the earth.

"Abraham Lincoln's carefully crafted address, secondary to other presentations that day, was one of the greatest and most influential statements of national purpose. In just over two minutes, Lincoln reiterated the principles of human equality espoused by the Declaration of Independence[6] and proclaimed the Civil War as a struggle for the preservation of the Union sundered by the secession crisis,[7] with "a new birth of freedom"[8] that would bring true equality to all of its citizens.[9] Lincoln also redefined the Civil War as a struggle not just for the Union, but also for the principle of human equality.[6]".

"Lincoln's address followed the oration by Edward Everett, who subsequently included a copy of the Gettysburg Address in his 1864 book about the event (Address of the Hon. Edward Everett At the Consecration of the National Cemetery At Gettysburg, 19th November 1863, with the Dedicatory Speech of President Lincoln, and the Other Exercises of the Occasion; Accompanied by An Account of the Origin of the Undertaking and of the Arrangement of the Cemetery Grounds, and by a Map of the Battle-field and a Plan of the Cemetery)."
 -- Wikipedia, Gettysburg Address
The books title is indictavite of the author's ability to thoroughly cover a topic. Everett's 2-hour oration had 13,607 words.



See Also:
     The Address by Ken Burns - PBS. Did you hear the story about the person that would give $20 bucks to grandkids that learned the Gettysburg Address? Encouraged me to learn it and it's history. History has an interesting emergent property... it appears to repeat, this is a emergent property from a complex system. It is the complex system practicing and learning... Humans as part of this universe's system, are so far (as we know) it's fastest learning sub-system. Our apparent loop duration is currently around Four Score years.Why President Obama Didn't Say 'Under God' While Reading the Gettysburg Address
Lincoln's 272 Words, A Model Of Brevity For Modern Times by Scott Simon

    Germany's Enabling Act of 1933. "The Enabling Act gave Hitler plenary powers. It followed on the heels of the Reichstag Fire Decree, which abolished most civil liberties and transferred state powers to the Reich government. The combined effect of the two laws was to transform Hitler's government into a de facto legal dictatorship."
     Women's March 2017 "A series of worldwide protests on January 21, 2017, in support of women's rights and related causes. The rallies were aimed at Donald Trump, immediately following his inauguration as President of the United States, largely due to his statements and positions which had been deemed as anti-women or otherwise reprehensible."
     Reichstag Fire Decree - Germany 1933  According to Rudolf Diels, Hitler was heard shouting through the fire "these sub-humans do not understand how the people stand at our side. In their mouse-holes, out of which they now want to come, of course they hear nothing of the cheering of the masses."[1].   Seizing on the burning of the Reichstag building as the supposed opening salvo in a communist uprising, the Nazis were able to throw millions of Germans into a convulsion of fear at the threat of Communist terror. The official account stated:  The burning of the Reichstag was intended to be the signal for a bloody uprising and civil war. Large-scale pillaging in Berlin was planned for as early as four o’clock in the morning on Tuesday. It has been determined that starting today throughout Germany acts of terrorism were to begin against prominent individuals, against private property, against the lives and safety of the peaceful population, and general civil war was to be unleashed…[2]
     TrumpCare: In the Beginning by Bill Frist - Nov. 2016, Forbes.  "Yesterday Americans woke up to news of a new president-elect: Donald J. Trump. The immediate question for those whose lives focus around lifting the health of individual Americans is, “What does this mean for health care in America?”
Categories: Blogs

Blog Series: TDD and Process, Part 3

NetObjectives - Thu, 04/06/2017 - 11:52
Part 3: Reusing the Specification I’ve said that notion of automation should follow the TDD specification process, not lead it.  We choose the “test automation framework” (TAFW) based on the nature of our specification and how we have chosen to represent it to stakeholders. That said, once we have settled on a TAFW, we can then determine how best to use it to bind the specification to the...

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

Groundhog Day at the Agile Transition Initiative

Now that everyone knows about Bill Murray's movie Groundhog Day - I love February 2nd.  It's my favorite, most enjoyable, beloved, cherished, esteemed day of the year.  And I don't need to tell you again how many LIKES I give this redundant day... so on to the story.

Bill & Groundhog
Well this happened about ten years ago, and about 6 years ago, or maybe it was 4 years past, and seems like we did this about 24 months ago...  or it could be today!

The Agile Transition Initiative at the company has come upon an inflection point (do ya' know what that is...  have you read Tipping Point?).  I'm not exactly sure of it's very precise date... but Feb. 2nd would be the perfect timing.   The inflection has to do with which direction your Agile Transition Initiative takes from this point into the future.   Will it continue on it's stated mission to "transform" the organization?  Or will it stall out and revert slowly to the status quo?

How do I recognize this perilous point in the agile trajectory?  Well there are several indications.  But first we must digress.


[We must Digress.]
Punxsutawney Phil Says more Winter in 2017In this story we will use the germ theory as a metaphor.  Germ theory came about in about ... (wait - you guess - go ahead ...  I'll give you a hundred year window... guess...). That's right! "The germ theory was proposed by Girolamo Fracastoro in 1546, and expanded upon by Marcus von Plenciz in 1762."  Wow, we've know about these little buggers for a long time.  And we started washing our hands ... (when...  correct -again).  "The year was 1846, and our would-be hero was a Hungarian doctor named Ignaz Semmelweis."  So right away business (society) started using a new discovery - a better way to treat patients.... or well it took a while maybe a few months, or maybe  more than 300 years.

But back to the metaphor - in this metaphor the organization will be like a human body and the change initiative will take the roll of a germ.  The germ is a change introduced to the body by some mechanism we are not very concerned with - maybe the body rubbed up against another body.  I hear that's a good way to spread knowledge.

We are interested in the body's natural process when a new factor is introduced.  What does a body do?  Well at first it just ignores this new thing - heck it's only one or two little germs, can't hurt anything - (there are a shit load of germs in your body right now).  But the germs are there to make a home - they consume energy and reproduce (at this point lets call it a virus - meh - what the difference?).  So the virus reproduces rapidly and starts to cause ripples... the body notices this and starts to react.  It sends in the white-blood cells - with anti-bodies.  Now I don't understand the biological responses - but I could learn all about it... but this is a metaphor and the creator of a metaphor may have artistic license to bend the truth a bit to make the point.  Point - WHAT IS THE POINT?

The point is the body (or organization) will have a natural reaction to the virus (change initiative) and when the body recognizes this change it's reaction (natural - maybe call it subconscious - involuntary).  Well let's just say it's been observed multiple times - the body tries very hard to rid itself of the unwanted bug (change).  It may go to unbelievable acts to get rid of it - like tossing all it's cookies back up - or squirting all it's incoming energy into the waste pit.  It could even launch a complete shutdown of all communication to a limb and allow it to fester and die, hopefully to fall off and not kill the complete organism.  Regaining the status quo is in the fundamental wiring of the human body.  Anything that challenges that stasis requires great energy to overcome this fundamental defense mechanism.

[Pop the stack.]
So back to the indicators of the tipping point in agile transitions.  Let's see if our metaphor helps us to see these indications.  The tossing of cookies - check.  That could be new people hired to help with the change are just tossed back out of the organization.  The squirts - check.  That is tenured people that have gotten on board with the change being challenged by others to just water it down... make it look like the things we use to do.  Heck let's even re-brand some of those new terms with our meanings - customized for our unique situation - that only we have ever seen, and therefore only we can know the solutions.  Folks, this is called the Bull Shit Reaction.

Now imagine a limb of the organization that has adopted the new way - they have caught the virus.  There is a high likely hood that someone in the organization is looking at them a "special".  A bit jealous of their new status and will start hoarding information flow from that successful group.  Now true that group was special - they attempted early transition and have had (in this organizations realm)  success.  Yet there was some exception to normal business process that made that success possible.  How could we possibly reproduce that special circumstance across the whole org-chart?  Maybe we just spin them off and let them go it alone - good luck, now back to business.

What's a MIND to do with this virus ridden body and all these natural reactions?

Well we are at an inflection point... what will you do?
Which curve do you want to be on?  - by Trail Ridge Consulting
[What Should You Do?]
Say you are in the office of VP of some such important silo, and they are introducing themselves to you (they are new at the Org.).  They ask you how it's going.  You reply, well, very well.  [That was the appropriate social response wasn't it?] Then they say, no - how's the agile transformation going?  BOOM!  That is a bit of a shocking first question in a get to know each other session - or is it that type of session - what should you do?

I will skip to the option I chose ...  because the other options are for crap - unless you have a different motive than I do... and that is a very real possibility, if so defiantly DON'T DO THIS:

Ask the VP if this is a safe space where you can tell the truth?  Be sincere and concerned - then listen.  There response is the direction you must now take, you have ceded control of your action to them, listen and listen to what is not said - decide if they want the truth or do they want to be placated.  Then give them what the desire.  For example (an obviously easy example - perhaps); imagine that the VP said:  I want the truth, you should always tell the truth.

Don't jump to fast to telling the truth... how can you ascertain how much of the truth they can handle?  You should defiantly have an image of Nicholson as Colonel Nathan R. Jessep as he addresses the Court on "Code Red".


You might ask about their style is it bold and blunt or soft and relationship focused.  You could study their DiSC profile to see what their nature may tell you about how to deliver the truth.

Imagine you determine that they want it blunt (I've found that given a choice must people say this, and only 75% are fibbing). So you suggest that it's not going well.  The transformation has come to an inflection point (pause to see if they understand that term).  You give some archeology - the organization has tried to do an agile transformation X times before.  VP is right with you, "and we wouldn't be trying again if those had succeeded."  Now that was a nice hors d'oeuvre, savory.  The main course is served - VP ask why?

Now you could offer you opinion, deliver some fun anecdote or two or 17, refer to some data, write a white paper, give them a Let Me Google That For You link. Or you could propose that they find the answer themselves.

Here's how that might go down:  Ask them to round up between 8.75 and 19.33 of the most open minded tenured (5 - 20 yrs) people up and down the hierarchy; testers, developers, delivery managers, directors, administrators (always include them - they are key to this process - cause they know every thing that has happened for the last 20 years).  Invite them to join the VP in a half day discovery task - to find out why this Agile thing get's ejected before it takes hold of our organization. If you come away from this workshop with anything other than - culture at the root of the issue, then congratulations your organization is unique.  Try the Journey Line technique with the group.  It's a respective of the organizations multi-year, multi-attempts to do ONE THING, multiple times.  Yes, kinda like Groundhog Day.

See Also:

The Fleas in the Jar Experiment. Who Kills Innovation? The Jar, The Fleas or Both? by WHATSTHEPONT


Categories: Blogs

Dash off a Fiver to the ACLU

What can you do to save the world with an Amazon Dash Button?

Has a new era of enablement reached the hockey stick curve of exponential growth?  I think it has.  I've been picking up this vibe, and I may not be the first to sense things around me.  I've got some feedback that I very poor at it in the personal sphere.  However, on a larger scale, on an abstract level, in the field of tech phenomena I've got a bit of a streak going.  Mind you I'm not rich on a Zuckerberg level... and my general problem is actualizing the idea as apposed to just having the brilliant idea - or recognizing the opportunity.

A colleague told me I would like this tinker's Dash Button hack.  It uses the little hardware IoT button Amazon built to sell more laundry soap - a bit of imaginative thinking outside of the supply chain problem domain and a few hours of coding.  Repurposing the giant AWS Cloud Mainframe, that the Matrix Architect has designed to enslave you, to give the ACLU a Fiver ($5) every time you feel like one of the talking heads (#45) in Washington DC has infringed upon one of you civil liberties.


Now I think this is the power of a true IoT the fact that an enabling technology could allow the emergent property that was not conceived of in it's design.  No one has really tried to solve the problem of the democrat voice of the people.  We use the power of currency to proxy for so many concepts in our society, and it appears that the SCOTUS has accepted that currency and it's usage is a from of speech (although not free - do you see what I did there?).  What would the Architect of our Matrix learn if he/she/it could collect all the thoughts of people when they had a visceral reaction to an event correlate that reaction to the event, measure the power of the reaction over a vast sample of the population and feed that reaction into the decision making process via a stream of funding for or against a proposed policy.  Now real power of this feedback system will occur when the feedback message may mutate the proposal (the power of Yes/AND).

I can see this as enabling real trend toward democracy - and of course this disrupts the incumbent power structure of the representative government (federal republic).  Imagine a hack-a-thon where all the political organizations and the charities and the religions came together in a convention center.  There are tables and spaces and boxes upon boxes of Amazon Dashes Buttons.  We ask the organizations what they like about getting a Fiver every time the talking head mouths off, and what data they may also need to capture to make the value stream most effective in their unique organization.  And we build and test this into a eco-system on top of the AWS Cloud.
"You know, if one person, just one person does it they may think he's really sick and they won't take him."What would it take to set this up one weekend...  I've found that I'm not a leader.  I don't get a lot of followers when I have an idea... but I have found that I can make one heck of a good first-follower!

"And three people do it, three, can you imagine, three people walking in singin a bar of Alice's Restaurant and walking out. They may think it's an organization. And can you, can you imagine fifty people a day, I said fifty people a day walking in singin a bar of Alice's Restaurant and walking out. And friends they may thinks it's a movement."I will just through this out here and allow the reader to link up the possibilities.


Elmo From ‘Sesame Street’ Learns He's Fired Because Of Donald Trump’s Budget Cuts.  Would this be a good test case for a Dash Button mash up to donate to Sesame Workshop.

See Also:

GitHub Repo Donation Button by Nathan Pryor
Instructables Dash Button projects
Coder Turns Amazon Dash Button Into ACLU Donation Tool by Mary Emily O'Hara
Life With The Dash Button: Good Design For Amazon, Bad Design For Everyone Else by Mark WilsonHow to start a movement - Derek Sivers TED Talk
Categories: Blogs

Thinking About Cadence vs. Iterations

Johanna Rothman - Wed, 04/05/2017 - 17:42


Many people use an iteration approach to agile. They decide on an iteration duration, commit to work for that iteration and by definition, they are done at the end of the timebox.

I like timeboxing many things. I like timeboxing work I don’t know how to start. I find short timeboxes help me focus on the first thing of value. Back when I used staged-delivery as a way to organize projects, we had a monthly milestone (timebox) to show progress and finish features. The teams and I found that a cadence of one month was good for us. The timebox focused us and allowed us to say no to other work.

A cadence is a pulse, a rhythm for a project. In my example above, you can see I used a timebox as a cadence and as a way to focus on work. You don’t have to use timeboxes to provide a cadence.

A new reader for the Pragmatic Manager asked me about scaling their agile transformation. They are starting and a number of people are impatient to be agile already. I suggested that instead of scaling agile, they think about what each team needs for creating their own successful agile approach.

One thing many teams (but not all) is a cadence for delivery, retrospectives and more planning. Not every team needs the focus of a timebox to do that. One team I know delivers several times during the week. They plan weekly, but not the same day each week. When they’ve finished three features, they plan for the next three. It takes them about 20-30 minutes to plan. It’s not a big deal. This team retrospects every Friday morning. (I would select a different day, but they didn’t ask me.)

Notice that they have two separate cadences for planning: once a week, but not the same day; and once a week for retrospectives on the same day each week.

Contrast that with another team new to agile. They have a backlog refinement session that often takes two hours (don’t get me started) and a two-hour pre-iteration planning session. Yes, they have trouble finishing the work they commit to. (I recommended they timebox their planning to one hour each and stop planning so much. Timeboxing that work to a shorter time would force them to plan less work. They might deliver more.)

A timebox can help a team create a project cadence, a rhythm. And, the timebox can help the team see their data, as long as they measure it.

A project cadence provides a team a rhythm. Depending on what the team needs, the team might decide to use timeboxes or not.

For me, one of the big problems in scaling is that each team often needs their own unique approach. Sometimes, that doesn’t fit with what managers new to agile think. I find that when I discuss cadence and iterations and explain the (subtle) difference to people, that can help.

Categories: Blogs

Axosoft Dev Talk: Practical Category Theory

About SCRUM - Hamid Shojaee Axosoft - Wed, 04/05/2017 - 17:37

It’s time for another video in our Axosoft Dev Talk series! In the first of two talks about Practical Category Theory, David Koontz explains Semigroups and Monoids. Watch this video to learn more, and don’t forget to subscribe to our YouTube channel for more videos about software development.

Could your Git client list be represented as the monoid ""? Maybe you should add GitKraken!

Categories: Companies

Building an Experimentation Culture at Spotify

Scrum Expert - Wed, 04/05/2017 - 17:03
Running an experiment is trivial: Make a change and see what happens. Running experiments at scale, however, is a different story. It is not trivial to simultaneously run hundreds of experiments...

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

SoCraTes UK, Dorking, UK, June 15-18 2017

Scrum Expert - Tue, 04/04/2017 - 11:00
SoCraTes UK is an International Software Craftsmanship retreat for open-minded craftspeople and agile developers in Great Britain and abroad who want to improve their craft and the software industry...

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

Journée Agile Belge, Charleroi, Belgium, June 2 2017

Scrum Expert - Tue, 04/04/2017 - 09:00
The Journée Agile Belge is a one-day conference focused on agile software development approaches like Scrum that takes place in Belgium every year. Most of the presentations and workshops are in...

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

GitKraken v2.3

About SCRUM - Hamid Shojaee Axosoft - Tue, 04/04/2017 - 00:14

As you’re probably aware by now, we work hard to address the needs and requests of ye faithful users of your favorite Git client, GitKraken. Version 2.3 implements a widely requested feature that everyone here at Axosoft is excited to see in a release: Git hooks!

We’re aware that this has been a barrier that has prevented some users from being able to adopt GitKraken for use in their teams, where specific functionality during certain actions is an absolute necessity. With Git hooks support, we’re hoping that GitKraken now incorporates the best of both worlds: an intuitive and simple to use interface, with the super-user functionality of Git hooks.

What are Git hooks?

Well, a hook might be defined as a trigger. If you’re familiar with JavaScript, you’ve probably used hooks before, in the form of events. Event listeners can be set up to fire custom actions when certain events (e.g. click, ‘click’) occur. Those events might be considered “hooks,” since you’re ‘hooking’ into them to do what you need to do.

WordPress users might also be familiar with hooks in the context of action hooks. At certain points in a page or post being rendered, various actions are fired off, into which the programmer can hook custom functions to work with the information at hand at that point in the rendering process.

Git hooks are very similar. They allow a user to create custom scripts that fire off at certain points during Git processes. GitKraken does not require that you install Git on your system, so until now, that independence had meant no Git hooks support. But, with a lot of blood, sweat and tears, v2.3 allows you to hook your way to a bounty of control over your Git actions!

Watch this short video to learn about Git hooks, and to see how Git hooks work in GitKraken.

What hooks are supported by GitKraken?

Beneath each hook is a list of the actions during which GitKraken calls that hook:

  • pre-commit:
    • Commit
    • Amend
    • Merge Resolve
  • prepare-commit-msg:
    • Commit
    • Amend
    • Cherrypick
    • Merge
    • Squash
    • Revert
  • commit-msg:
    • Commit
    • Amend
    • Merge Resolve
  • post-commit:
    • Commit
    • Amend
    • Cherrypick
    • Merge Resolve
    • Revert
  • pre-rebase:
    • Rebase
    • Squash
  • post-checkout:
    • Checkout
    • Discard Changes (selectively)
  • post-merge:
    • Merge (Without Conflicts)
    • Fast-Forward
  • post-rewrite:
    • Amend
    • Squash
    • Rebase
  • pre-push:
    • Push Branch
    • Push Tag
    • Delete Remote Branch
    • Delete Remote Tag

So that’s Git hooks. We hope you enjoy getting your tentacles all up in our actions!

Regional Date Settings

Another widely-requested feature has been the ability to set region-specific display dates for commits. Y’all might not be from these here parts and might have some region-specific ways of presenting your dates. Viewing another format can be jarring and counter-productive when you’re trying to decipher dates at-a-glance.

Well, guess what? GitKraken will now think to itself, where am I? and will update its date format accordingly, based on your system locale. You’re welcome! De rien! Bitte schön! De nada! Don’t mention it! Pip pip! As you were.

New Onboarding Experience

It’s now easier than ever before to get the rest of your team set up in GitKraken. V2.3 introduces a brand new onboarding screen for first-time users. It’s easier to see where to set preferences and start working with repos. It also introduces users to our Intro to GitKraken video which gives a quick 90-second overview of GitKraken’s functionality, our support site which provides lots of helpful documentation, and the GitKraken Slack Community where our users come together to help each other and help our team improve GitKraken.

But, there is just one more thing…

Try GitKraken Pro for free

If you’ve been wanting to try out GitKraken Pro features—like the merge conflict output editor, multiple profiles for work and personal use, or GitHub Enterprise integration—nows your chance!

Start a free GitKraken Pro trial by simply clicking the 

button in-app. You’ll be able to test these awesome features for up to 14 days before deciding if you want to upgrade to a paid account!

Categories: Companies

Giving Better Feedback

Scrum Expert - Mon, 04/03/2017 - 18:36
The first value of the Agile Manifesto is about “individuals and interactions over processes and tools”. Communication is fundamental inside and outside the Scrum team. In his article...

[[ 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.