Put a Spike in It

Spikes are part of agile.

People outside of the software business think technology is magical.  People compare developers to magical elves from the fairy tale "The Cobbler and the Elves." At the drop of a pin, developers can create solutions and generate mounds of money from their efforts.  The reality is different.  Software development requires smarts, but it also includes constant pressure to meet deadlines and frustration as you try to solve problems.  It is not magic. Instead, it is grinding work.  The most misunderstood part of that work is the prototyping, research, and analysis necessary to create working software.  In agile, we call this work a "spike," and we will discuss it today on the blog. 

When you first learn agile, you realize the product owner writes user stories, and the stories reside in the product backlog.  The team then pulls those stories into a sprint, and work gets accomplished.  When we look at that work, it typically falls into two main categories: user stories and bugs.  A user story covers improvements or new functionality.  A bug or defect covers broken behavior in the application.  These two types of product backlog items make up most of the work done by the team.  The approach worked well for the construction and maintenance of a project but was insufficient for research and development. 

The realization that analysis and research are not adequately captured in the product backlog led to the spike's creation.  A spike is a special kind of user story in agile.  It represents proof of concepts and research.  The output of a spike is more user stories that contribute to sprint goals. 

Here is an example of a spike:

[Spike] Research PDF creation from License form

As a developer, I want to understand how to create a PDF file once a customer saves a license file because this is an upcoming requirement. 

-Use a third-party tool to create PDF's

-Then, save PDF as an attachment and email it to the customer.

This is a spike!  The outcome should be a proof of concept and more user stories.

As you can see, a spike looks similar to a user story.  The only difference is the acceptance criteria are vaguer to make it possible to conduct research.  It is also clear some tangible learning must result from the work.  The person assigned the spike should do the research and then help the product owner write the other user stories to meet a future sprint goal.

During the daily scrum, the team reports on what it is working on and what they are learning.  The spike also explains why the group may be working on fewer story points than usual because the research is taking up the team's mental bandwidth.  Thus, the three main items in a backlog should consist of stories, bugs, and spikes. 

A spike helps the team track research and development.  Using spikes allows the team to explain slow-downs in work.  Finally, a spike enables the team to prepare for future work without blundering into a mistake.  Spikes are a helpful tool in your agile toolkit; give them a try and see what you can accomplish.

Until next time.

Spring Cleaning for Agile

Keep the dust off your agile practice.

Late March is a strange time.  The weather is getting warmer, but the conditions alternate between sprint sunshine and winter mix, which is a depressing combination of rain, ice, and sleet which can drive a person to insanity in the space of an afternoon.  It is a time of transition and a perfect opportunity to think about spring cleaning.  

Spring cleaning is a tradition in northern climates where people throw open their windows and use the fresh air to dust and clean up the debris which settles in the house during the fall and winter months.  My mother and I would dust every surface, clean the windows inside and out, and we would wax floors and shampoo carpets.  It seems we were constantly cleaning this time of year.  

Keeping the house neat and organized was always important to my family. The world of business should also think about spring cleaning.  A business person should ask about the clutter around the organization.  As an agile coach, you should survey the chaos and inefficacy in your organization.  Ask questions and find out what is working and what needs to change.  The agile manifesto says teams and organizations should be responsive to change over following a plan.  Having a spring-cleaning mindset allows you to see what should change and then make that change happen.  

It is never fun to do housework, but once spring cleaning was complete, the house always felt shiny and new.  Doing what is necessary for your business will give you that same feeling.  So take a look around, grab a dust rag and do some spring cleaning for your agile.  

Until next time. 

Action Items Make the Retrospective Real.

Henny Youngman
can teach us scrum.

The most fundamental activity in agile is inspection and adaptation to changing circumstances.  A retrospective is a principal tool used by the agile team to respond to change.  Over time, a team can get stale in using the revelations of the retrospective to improve.  As I continue to talk about agile basics, I want to highlight an essential part of agile retrospectives; action items.

Legendary borsht belt comedian Henny Youngman would tell a joke about a man who goes to the doctor and tells them it hurts when they bend their arm a particular way.  The doctor always replied, “Stop doing that.”  Behind the simplicity of this joke is a bit of wisdom.  We are often hurting ourselves.  Many of the things breaking the team often originate from the individual members of the group.  Patrick Lencioni called many of these injuries the five dysfunctions of a team: inattention to results, avoidance of accountability, lack of commitment, fear of conflict, and absence of trust.  Many of the issues which come up during a retrospective have their origins in these dysfunctions.  

Recognizing a problem is only half the battle.  Improvement happens when recognition combines with sincere effort to fix the problem.  A scrum master then steps in, holding the team and its members accountable for making the change.  

The following is an example of a dialog between team members.  The team is struggling with quality and defects rollover from sprint to sprint.  The retrospective points out this problem, and the group agrees to get better at quality assurance.  Someone points out a spelling error in form validation, and it lingers two hours.  

Scrum Master: “Did anyone fix that spelling mistake? It is defect-123.”

Developer #1: “What spelling mistake?”

Scrum Master: (checking the Kanban board) “The one we found two hours ago.  Who worked on that page?”

Developer #2: “I did last week.”

Scrum Master: “Cool, do me a favor and write a unit test and fix the spelling mistake.”

Developer #2: “Developer #1 has the branch checked out.”

Scrum Master: “Ok, Developer #1 gets to write the test and fix the code and do the commit.”  (points to Developer #2). “You can pair with them until it is done and meets the standard of care.”

Developer #1: “Ok, give me about thirty minutes.”  

Scrum Master: “Thanks, and let me know when you merge the code.” 

When fixing a spelling mistake on a web page, whether JavaScript or text, should not take a developer much time.  It will take longer to write a unit test and have someone review the changes.  It is up to the team members to point out these quick fixes and hold each other accountable.  On a more mature team, developer #1 and developer #2 would have taken care of the defect when first spotted.  The difference between the two scenarios is a significant improvement in code quality and fewer defects rolling over from sprint to sprint.  

Only through constant attention and friendly reminders to the team will they internalize the lessons from the retrospective.  It is up to the scrum master to be that force of change.  Action items are nothing more than commitments the team makes to change for the better.  Instead of reducing bugs, the team should strive for better quality, eventually leading to fewer bugs.  Unit tests will not reduce the number of defects in a system, but they will reduce and spot future flaws before they become embarrassing.  

Henny Youngman was right.  If the team thinks it is doing something wrong, stop doing it.  Taking action on an item from the retrospective will improve the team and save time and energy.  

Until next time. 

The Ugly Duckling of Agile Rituals

Get your ducks in a row with a sprint review.

The scrum guide talks about how you should run the flavor of agile, known as scrum.  As part of the empiricism of agile the development team inspects and adapts depending on market conditions.  Some people feel that the most important meeting is the retrospective, where the team reviews how the sprint is going.  The sprint review meeting is the most important because the customer gets to see the development team's progress.  Today, we continue to talk about agile basics but take a closer look at the ugly duckling of scrum rituals – the sprint review.  

According to Scrum.org, a sprint review is when the scrum team presents the results of their work to customers and clients.  The meeting allows everyone to discuss how close they are to meeting product goals.  It can be as formal or informal as the team needs as long as it has three characteristics. 

The first characteristic is members of the development team should attend.  The purpose of this is to see how the customer or client uses the software.  For example, on a web application, the browser button allows you to go back.  If the page loads slowly, the user will instinctively click the "back" button.  The back button might change the application state of the data and corrupt information.  If a developer sees the customer's frustrations and challenges, they will program the customer's application in mind. 

The next characteristic is the sprint review should be led by a non-technical professional.  Non-technical people will use the application, so a non-technical person should lead the discussion.  The product owner or client should review the work and improvements to the software.  When this happens, it allows the client to experience the software as a typical consumer.  It also provides the development team with another perspective on how the software should operate.  

The final element is that the demonstration should be as close to a production environment as possible.  Plenty of things can go wrong when authoring software.  Often code that works on a local machine will break when promoted to a new environment.  It is why that code should be strong enough to be demonstrated in a testing environment as close to production as possible.  It avoids oversites of database connection strings, file pathways, and DNS entries not pointing to the correct settings.  It also exposes the team to the displeasure of the client who expects the product to work.  Host the product review in as close a production environment as possible. It will save you the financial and reputation embarrassment of a production failure. 

Having developers present during a sprint review, a non-technical person who leads the meeting, and has the environment as close to production as possible will make your sprint review informative.  A useful sprint review will inform the team retrospective and sprint planning.  It will also build trust between the software development team and the client.  Trust will be invaluable when things go wrong, which is inevitable in any software project.  

The sprint review is the ugly duckling of the scrum rituals, but if done correctly, it will make your agile process more robust and more resilient to change.  

Until next time. 

Navigating the Fog of Uncertainty

The natural state of projects is fog.

Recently, I have been focusing on the basics of agile.  Master those simple skills and rituals and it will make you a better coach and scrum master.  Today, I want to focus on something which is your constant companion in business: uncertainty.  The ability to deal with uncertainty, mitigate risk, and address the unknown are essential business skills. 

When project managers discuss uncertainty in a project, they are all the unknown factors that crop up.  There is no right way to understand all the nuances of a project until you begin work and experience them.  Plans are helpful, but they often rely on assumptions that do not exist.  A plan usually takes for granted the people doing the work are all the same and have the same training and experience.  A plan also assumes that conditions will not change throughout the project.  When confronted with the realities and nuances of a project, the plan often shifts or is discarded.  

It is why project people have come up with the term “cone of uncertainty.”  At the beginning of a project, the estimate of time can vary significantly.  If you are fortunate, completing the work may take a fraction of the time allotted.  Often, a project will run over time and budget because the team did not know the hidden factors involved in completing the effort.  As the team continues to work with the project, the uncertainty narrows, known as a cone.  As time goes on, the team has a more realistic understanding of what needs to get done to finish the work.   

It helps understand the cone of uncertainty because it provides a helpful guide for people outside of the project to understand what is going on inside.   Often the situation is more confusing, and I use the term “fog of uncertainty.”  When the problem is more confusing, and people are fumbling around looking for a horizon or clear direction.  Like backpackers lost in the fog, they are stumbling over the ground, walking in circles, and easily distracted by strange sights and sounds.  As a business leader, you will face these situations.  

When in a fog of uncertainty, the team will fight over which direction to take.  Each stumble could escalate into a major crisis.  Finally, deep anxiety will take hold, and it will undermine the effectiveness of everyone.  It is at this point that a project fails because its goals are most concealed. 

Just like hikers in the wilderness, there are some techniques you can use to avoid getting lost.  One of these methods is to rely on a compass to maintain a direction.  In a corporate environment, executives fill this role pointing people in the correct direction and providing landmarks for people to follow.  An executive cannot banish the fog, but they can provide help when necessary.  Next, the team can do rapid inspections and make sure they are not going in circles.  The developers can rely on known facts and then use them to build out where they go.  It is why database models and UML diagrams are helpful because they behave like maps for the team.  Small common-sense tricks and experience can make uncertainty manageable.  

As the team progresses, uncertainty dissipates.  When the path becomes more evident, the team can move faster toward its destination.  The skills they use to navigate through the fog are still helpful and will further create certainty on the project.  I find these techniques work well with a no-estimates approach or with story points. 

So to navigate the fog of uncertainty, use the tools of agile to find your way.  Do rapid inspections of work and adapt to changing conditions.  Use executives or clients to provide direction and guidance.  Finally, clear landmarks like UML or Data maps can help make life easier for the team.  Being stuck in fog is awful, but you will reach your destination by taking a few simple steps and careful navigation.  

Until next time.