Be a Flashlight

As the year ends, I thought I would like to stand back and review why agile is so powerful. Using an agile approach manages many of the challenges we face in the delivery of software. By following a simple set of principles and processes we can improve our chances of success.
The reason agile works is it focuses on adding the business value the customer wants based on her priority under an iterative delivery approach. It does this in a predicable manner without overworking the team. Progress is monitored using a small set of reports and frequent demonstrations of completed software.

The team remains productive because regular short meetings monitor progress and identify roadblocks. A switch from a Command and Control approach of a typical project manager to a more Self-Governing style improves productivity. The project manager role moves from a director to a facilitator.

The term Agile Coach has started to gain popularity. I prefer this to Scrum Master because my experience in the real world has shown me a mix of Kanban, Scrum and Extreme Programming is typically required.

So how can a team be Self-Governing? How can a group of people get the right thing done without being told what to do?

I believe most people want to feel good about their work and want to do the right thing. What causes most people to deviate from this is frustration and a feeling of despair. When people just show up for work and do what they are told, even when they know it does not make sense, productivity and quality suffers.

I view the job of an Agile Coach is to “Be a Flashlight”. Shine light on areas that “smell” and ask pertinent questions.  The reason this works is it affects aspects of human nature both positive and negative and leverages success. Let’s take a look at some of them next:

• Being Told What To Do – People do not like to be told exactly what to do. This is especially true with programmers. These creative people want room to grow their craft. By providing direction without being a micro-manager, people will be more motivated.
• Shared Accountability – Everyone moves off track from time to time. What typically causes frustration is when this occurs and the team feels nothing can be done about it. We need everyone to feel they can ask any question about anything. By asking these questions we shine light on uncomfortable areas. When a mistake is made, the person who made the mistake is accountable. Now this is not blame. Over time the team learns that mistakes are inevitable and eventually everyone will make one. We identify the error, correct it and move on.
• We are in this together – People respond and engage when they feel they are part of a larger thing. It is bigger than just the individual.
• Peer Pressure – people do not want to look stupid. They want the respect of their peers and their bosses. The complete transparency of agile causes everyone to know what is going on without having to point fingers at individuals.
• We always did it that way – when people feel they are trapped and helpless in a situation that will never change, they come to work, do their thing and go home. Both productivity and quality suffer.

It is the job of the Agile Coach to work through project challenges. Agile has process and guidelines to handle all of this. We will explore some of these next and highlight how being a flashlight and asking questions rather that giving orders manages the human nature in all of us.

Business Value

The whole team knows it is all about business value. We build features that add the most business value early. It is the job of the Product Owner to place the features in the backlog in the proper order.
The Agile Coach watches the backlog and looks for “smells”. She may say to the Product Owner

“I seem to remember that we discussed moving the forgot password feature later in the backlog but I still see it in the next sprint. Did something change?”

Just asking this question shines light on a situation and it will work itself out.

Daily Standups

Each day there is short meeting where each person reports progress and impediments. Everyone on the team knows this meeting happens and each day they report progress. The progress is reported to the team, not to a command and control project manager.
This meeting exercises all of the human nature points we discussed. Peer Pressure will cause people to be motivated to get their tasks completed. Openness and transparency causes people to raise issues when something is an impediment. When one team member has a problem and is helped out by another team member we see we are all in this together.
When a person reports the same progress on a task for a while and begins to run late, the Agile Coach may ask

“ May I help you on that task in any way, you seem to be struggling with it?”

There could be many answers to this question. Again by shining light we will get a solution and the team figures it out.

Iterations

We deliver a set of features that meets the definition of "done" in short periods of time. The team agrees to the following:

• Definition of done
• Length of iteration
• Features to be included in a given iteration
• New features can always be added, but not to the current sprint

The important thing is that the Team agrees to these things. It is the job of the Agile Coach to facilitate this agreement. If the team does not agree, most of the power of agile is diluted. The job of facilitator is critical. When the team does agree, things are easy. Let’s look at some examples.
The Product Owner says:

“I have a hot new feature we need to add to this sprint, please add it and let me know the effect”

The agile coach says:

“We agreed to two week sprints. We are 5 days into this sprint. Is it possible to wait 5 days for the new feature?”

Normally, requests like this come out of anxiety. The product owner was probably pressured by her boss to get this feature in right away. The boss may not even know the project is agile. Your job as an agile coach is to help the product owner, so her answer aligns with what the team agreed to. You may need to talk to her boss and explain why we need to wait five days and explain the disruption the request will cause. The agile coach helps the product owner in dicey situations. Normally, the Product Owner will see the logic of waiting and will agree.
During a standup meeting the Agile Coach Says:

“Thank you everyone for your updates. I noticed that there are no impediments, which is good. However, I notice we are above the ideal line on our burn down chart. Are we still confident that we can complete the features we all agreed to at Sprint Planning?”

A person from the testing team says:

“Well if the login feature is completed on Thursday, that only gives us one day to test it and my estimate was two days”

The agile coach continues the dialog, asking probing questions until the team discovers a solution.  The coach uses her analytical and negotiating skills to probe in areas the individual team members do not readily see.

Some Good Information

In closing out the year, I wanted to pass on three links that provide very useful information and an excellent book on learning to be an agile coach.
Coaching Agile Teams, by Lyssa Adkins is an excellent book for anyone who wishes to become a better agile practitioner. I use Lyssa’s tips and practice her advice every day. A link to Lyssa’s Blog is available at http://www.coachingagileteams.com .
An excellent video on Scrum is available by a vendor who sells the agile tool OnTime. I am not typically one to recommend a specific tool without understanding more about the given situation, but I can recommend the video Scrum in 10 Minutes. It is one of best short descriptions I have seen on Scrum.

I just learned about this video today after reading about it in an agile group on Linkedin. It is titled Agile Project Ownership in a Nutshell but really covers the agile philosophy as well as I have seen anywhere. You are also left with a very good diagram.
There is an excellent roadmap to all things agile hosted by the Agile Alliance. This clickable map is presented in the format of subway station stops.

You may find this excellent resource at the Agile Alliance web site here.
Finally, I want to wish everyone a great 2013.

Manage your time using the Agile Technique of Kanban

I have read two blogs recently that I found very informative and caused me to change the way I work.
Jim Riviello’s blog titled Less is more discusses the importance of identifying what you should work on next is critical to being productive. He says in his blog
         “Don’t confuse activity with productivity”
Jim also discusses the power of three and recommends maintaining three lists to manage your work. As I read this, my agile mind kicked in and I thought this sounded familiar.
Later that week, I read Lyssa Adkins blog titled Just me and my kanban board. Then it clicked, Jim’s idea of three lists sounded a lot like the Agile technique of Kanban.  I never even considered using Kanban to manage my to do list until I read Lyssa’s blog.

Kanban

Kanban is a process scheduling technique developed by Toyota and later modified to be part of the lean and agile software development methodologies.
In Kanban we use a set of swim lanes to divide up our work. Everything that we plan to do resides in one of these swim lanes. What makes Kanban powerful is these lanes are gaited with the maximum of items allowed in a given lane. This make us focus on completing the work in a gated swim lane before adding another item.

In Lyssa’s blog, she mentions using a mini white board and post it notes to manage her swim lanes and tasks. Agile is all about simplicity and this is an excellent and simple technique. Lyssa uses Kanban For 1 for this purpose.

My Personal Kanban

I decided to use a software solution for my Personal Kanban. I found a free Kanban tool at https://leankitkanban.com/ .

My Personal Kanban board is shown below. I have four swim lanes in my board.

• ToDo – this is something I know I need to do some day. As I think of things during my busy day, I add it here. At regular intervals I prioritize my ToDos by dragging them to the proper position in the swim lane.
• Planning to do – These are items I plan to do soon. I have gated this to 5 items.
• Doing – these are items I am actively working on. Since I decided I could only be working on 2 items at a time I gated this to 2 Items.
• Done – these are items I have completed.

I have established the following rules for myself:

• I can add items in ToDo any time in the day.
• At least one a day I spend 5 minutes reviewing and prioritizing the items in ToDo.
• I spend time each day deciding what I will do soon by moving items into Planning to do. Again, no more than 5 minutes.
• When I start a new task, I always move it onto Doing. This is gated to 2 items. I do not exceed the 2-item gate.
• When I have completed an item, I move it to done.

All of this is very easy to do by dragging and dropping with a mouse.  In my Kanban board shown below, please note the Yellow 5. This tells me I am have reached my gated limit.



Look what happened when I exceed a limit, I get warning and have to enter a reason.



When I decide to proceed anyway and enter a reason, my swim lane looks like this.



I have been using this technique for about a month and I have caught myself many times going down a rabbit hole into things I should not be working on. My personal Kanban board has kept me honest, maybe it will work for you too.

Automated Builds - Test Driven Development

Introduction
Your development process can be improved if you automate your build process and implement some form of test driven development. All of us have been on projects where the integration phase takes a long time, often longer that the development time itself.
By taking steps toward automated builds and test driven development over time, you will make the integration process a non event. The mantra is “Find as many issues as possible, as early as possible”.
The first step toward automated builds is to develop a script that extracts everything from version control and builds your system using one command. The goal is to be able to visit an empty machine and build your app with this single command.
This means that everything you need for you application should reside in version control. This includes database schemas, stored procedures, views, seed data, source code and ideally, unit tests.
If the build succeeds, an installation package is created and success notification emails are sent to a distribution list. This installation package is stored in a drop folder and made available to anyone who needs it.
nAnt is a good open source tool that can perform these tasks.

Version Control
The heart of automated builds is Version Control. Everything necessary to build your application should reside here.
Your database schema represented in the form if a SQL script resides in Version Control. Ideally, this script should be created using a database modeling tool. The modeling tool creates the script and is stored in version control.
All of the scripts necessary to create your stored procs, views and other programmatic database objects reside in version control as well. A master script that executes these scripts in the proper is also required. It is not a good idea to develop database objects directly in the database. Always develop database objects via scripts.
The final database task you face is the scripting necessary to populate seed data. This could be lookup tables and other data necessary to operate your application.
Of course, all of the source code for you application must reside in version control. It is also suggested to include the source code for your unit tests. nUnit is a very good open source tool for unit testing.
When a build is successful, we will create an installation package. This could be as simple as a zip file with installation instructions or an MSI file to automate the install. Anything necessary to facilitate the install should be in version control as well.

The Build
A single command should perform the build. nAnt is an excellent scripting based on the popular Ant setoff tools in the J2EE world. nAnt should perform the following general steps:

• Cleanup – Perform any cleanup from a previous build. Delete any executables, config file or other objects.
• Drop Database – Drop the database that was created from previous builds.
• Extract From Version Control – Extract the files from version control.
• Build the Database – Create a new empty database. Execute the schema script, Script for Procs and views and seed data script.
• Compile the application – Perform a compile of the application and unit tests.
• Execute the Unit tests – Use the batch option to execute all of the unit tests for the application.
• Failure action – If any of the above steps fail, send a failure notice and log to failure distribution list.
• Success action – If the build succeeds, build an installation package and send an email to the success distribution list. The installation package is available to QA or anyone who need it.

In Closing
Even though it is a challenge to get an automated build setup the first time, it is worthwhile. If the build is run every night, problems are uncovered on a daily basis instead of being pushed to the end of the project.
The following links provide useful information on this topic:

• nAnt Home Page – Used to automate builds ( http://nant.sourceforge.net/ )
• nUnit Home Page – Used to develop unit tests ( http://www.nunit.org/ )
• Continuous Integration – Very good article that describes how this idea benefits development projects http://www.martinfowler.com/articles/continuousIntegration.html )

Don't have enough time to do a task - Time Box it

We have all faced with the situation where there is too much to do an not enough time to do it. Sometimes the technique of Time Boxing can save the day.

Time Boxing is useful when you have tasks like documentation, specifications or other analysis type work.

Say we have a system that need analysis performed. You estimate it will take 200 hours to complete the task. Well, what if you only have 75 hours.

The trick is to cover the width of the problem domain without going into the depth completely. So, as the diagram on the right depicts, you cover the problem domain an inch deep and a mile wide instead of covering the whole topic. The trick is cover enough width to have a meaningful deliverable.

It takes a bit of practice, but over time you will gain experience with this approach.

Are your clients reading your documents?

I was working at a client a few years back. Lets call this client Futz Inc. Futz was building a very complex application that was getting ready to go into the construction phase. Just as the construction phase began, the final version of the specification was sent to the copy center(this was before email was mainstream).
The cover letter of the specification asked the folks to review the specification and get back with any comments.
Well, the copy center made a mistake. Because this was a large document, they printed the specification duplex, or a page on each side of the paper. They accidentally skipped every other page of the specification.
So, the specification was obviously incorrect with every other page missing. Well, no one got back with comments. So, no one read the specification.
Since then, I use a trick. If I believe my customer is not reading my documents. I place an obvious error in the specification. For example I may say "There is one square wheel on the wheelbarrow".
If the customer says "Scott, we should not have the wheel square" I say, "Oh what was I thinking, of course it should be round, sorry".
But, if the customer does not ask me about the square wheel, I know to be very careful. I schedule meetings with the customer where i walk through the system in detail and ask questions.
So, if you want to see if your customers are reading, your stuff, make an obvious mistake and see for yourself.