Global SCRUM GATHERING® New Orleans 2014 - The Product

My last blog post covered some important points I took away from the Scrum Alliance Global Scrum Gathering in New Orleans that pertained to The Team. This was an excellent conference and I learned many new things. Also, practices that I use regularly were expanded and important details were added to my knowledge base.
This post is about The Product. My final post will be for The Scrum Master.

The Product

I focused my session attendance on Product Planning, User Story development, User Experience and Execution.

Product Planning

One of the sessions I attended used the MoSCoW planning technique combined with Size and Dependency of stories.

The MoSCoW technique organizes stories as follows:

• Must Have
• Should Have if all possible workarounds exists
• Could have if not affected by anything else
• Would like in the future but not necessary now.

We then identify the size of the story using your favorite size measure along with any dependencies.

We identified priority as follows:

• Small Must Haves are at the top of the backlog, larger stories follow.
• Dependent stories are included with the must haves.
• Should Haves and their dependencies are next.
• Could Haves and their dependencies are next
• Would like to have are last.

We decide what fits into a sprint or release by reviewing order of the stories in the backlog and their dependencies. Our velocity may require us to shuffle the backlog order to accommodate story dependencies.

This seems to me to be a good alternative to simple drag-and-drop for stories in a backlog. I will look for an opportunity to use this in one of my future projects.

Estimation

The closing keynote was presented by Richard Sheridan of Menlo Innovations. This keynote got a standing ovation and I recommend that you take the time to watch it.

Menlo uses a very simple process that closely follows XP practices. For estimation, they estimate their stories in hours. They use hand written stories and post them on the wall.

The physical paper for each story is folded to represent the size of the story. A 16 hour story is an 8 ½ by 11 sheet of paper. An 8 hour story is folded in half. A 4 hour story is folded in half again.

A planning sheet is used that represents the capacity for a week’s worth of work. At planning meetings, Menlo’s clients place the folded sheets they want delivered in the next week on the planning sheet. 

This simple and unambitious approach struck me as very powerful. It shows what will be delivered and more important, what will not. Watch the keynote to see the details of this and much more.

User Stories

I attended a very interesting session that presented a simple technique for splitting user stories. This very simple technique recommends:

• Conjunctions – look at connector words like and, or, if ect.
• Generic Words – look for generic words that can be replaced with more specific terms.
• Acceptance Criteria – look at a stories acceptance criteria, perhaps it can be another story.
• Timeline Analysis – pretend a story is done. Review what happens when the story is used. This may lead to smaller stories.

All of these points are available on a single Quick Reference Guide.

It was also recommended that stores be split by a non-technical person.

I also noticed that many people at the conference use personas as a way to define user stories.

User Experience

The topic of user experience came up a number of times. Menlo actually develops separate stories for UX work. One person mentioned the term Lean UX.  A book is available in addition to the blog post.

An interesting point some mentioned about lean UX is using low fidelity artifacts like paper prototypes.

Execution

The opening keynote was by Kenneth Rubin who wrote the book Essential Scrum. He used the analogy of a relay race. He pointed out that we should Follow The Baton Not The Runner. The point here is the deliverable is what is important.

In relation to planning, he pointed out that the reason we plan, is to make meaningful decisions and have a reasonable chance for success. 

Throughout the conference I heard people mention the Last Responsible Moment and Definition of Ready. I plan to keep these concepts in the front of my mind more in the future.

Learn More

• Lean UX Blog Post 
• Lean UX Book 
• Splitting User Stories 
• Menlo Innovations and Joy Inc Book – everyone who delivers software should read this book 
• Follow The Baton Not The Runner 
• Global Scrum Conference New Orleans Keynotes 

Global SCRUM GATHERING® New Orleans 2014 - The Team

I just returned from the Scrum Alliance Global Scrum Gathering in New Orleans. This was an excellent conference and I learned many new things. Also, practices that I use regularly were expanded and important details were added to my knowledge base.
My next few blog posts will outline some of the things I found important. I will also provide links to books and vendor products I found interesting.
I have divided my comments into three categories,The Team, The Product and The Scrum Master. This post is about the team.

The Team

I learned as much from the people attending the conference as I did from the session speakers. This was especially true with the team.
The term T-Shaped Skills was used to describe a cross functional team. The diagram below depicts cross functional ability in an easy to understand manner.

Many times the notion of handling different team dysfunctions and personality types came up. A common idea is to have the team come up with a solution. A tangible way to do this is to have the team come up with Working Agreements and Ground Rules. Since the team came up with the details, when a rule or agreement is broken, it is easy to remedy.

Teams are often uncomfortable trying new things. In this case it is good to point out that we are not sure this will work and that we will Run an Experiment to see. This makes people more comfortable with the unknown.

Distributed teams are becoming more common. This is not just because of offshore teams. More and more firms have their employees spread across the USA.

The points below were mentioned as ways to ease the pain with distributed teams:

• Tools – there are a number of tools available that allow distributed teams to work better together. See the section on Vendor Solutions below for the tools that were mentioned.
• Google Spreadsheet – this was mentioned as a collaboration tool because when multiple users work on a single document, the change is annotated with the user’s name in real time.
• Skype – one person mentioned that they have a computer on and available at each remote location at all times. This allows for easy adhoc meetings when a few people need to meet.
• Big Monitors Everywhere – one of the best way to provide transparency is to hang or draw burn down charts and other agile artifacts on the wall. With distributed teams, this is not possible. It was agreed that having the charts “available” in a tool is not sufficient. One attendee mentioned that he had big monitors in all locations displaying the agile artifacts. 

I will follow up this post soon with points about The Product and The Team.

Learn More

• Work Agreements
• T-Shaped Skills
• Run an Experiment

Vendor Solutions

• Video Teleconferencing Solutions by Cisco
• Virtual Office Software Solution 

Improve Your Process Using Kanban

Kananban was developed in the late 1940's by Taiichi Onho at Toyota to improve Toyota's production process. It is important to note, this had nothing to do with software, it was all about managing Process and Work. This post will explore using lean principals and Kanban to manage a team's process.

The Problem

Before we offer a solution it is worthwhile exploring what problem we are trying to solve. Teams and the people who work on them are very busy and over worked. They have too much to do in the normal work week. This causes them to work many additional hours just to keep their heads above water.

Teams are also juggling many things at the same time. Many people are proud of their ability to multitask. Although acceptable in small quantities, multitasking can actually lead to lost productivity ¹. It is easy to have so many spinning plates that some are bound to fall and break.
We are faced with so may things to do, we often do not know what to work on next. This causes teams to work on items that may not be that important. Our items get lost in a blizzard of work and we feel lost. This causes a lot of waste.
We are so busy, that we often do not take the time to improve. We feel we are so busy this is not possible. This causes us to get mired down in our same old way of working.
As teams move toward an end goal the progress is also lost in this blizzard. Like a blinding snow storm,there is not transparency into what the team is doing and how it is progressing toward a goal.
It very competitive out there. It is critical for teams to work at peak efficiency. They need to know What is needed and when it is needed. They need to eliminate waste, have a transparent process that helps teams know what is going on and have a way to learn and adapt in a way that does not take lots of time.

The Kanban Solution

Our Diagram below depicts a simple Kanban Board.

We uses a set of Columns that define the workflow of our process. In this example, it is very simple. The workflow moves from left to right.

A set of Cards identify what we need to do. The cards are in priority order, the most important cards are at the top of the list.

It is best to have a card identify an outcome that has value. This is better that a set of tasks. For example Desk ready to ship is better that Order Desk.

 A Constraint identifies the maximum number of cards allowed in a column. In our example, we only allow 3 cards in the doing column.
It is very easy to setup a Kanban board. A good place to start is a whiteboard and post it notes. There is also free software that can easily setup Kanban boards, Please see our Agile Tools for Delivery section for details.

Why Do This

Using Kanban forces us to put some thought into our process. By defining a set of Columns we define our workflow. By adding Constraints to a column we are acknowledging we have limited resources and have agreed to finish what we start before moving on to other things.

A set of Cards identify the things that need to be done and the priority they are needed. All of this is transparent for the whole team to see. This allows the team the see what is going on at all times and adapt where needed.

Regular meetings should be conducted to review the work and adapt to change.
For an working example please see the Process Improvement with Kanban section of our Roadmap to Agile.

Learn More

What is Kanban

Introduction To Kanban

Just-in-Time - Philosophy of complete elimination of waste

Some Remarks on the History of Kanban

Lessons in Agile Management: On the Road to Kanban (Book)

1. Debunking the Myth of Multitasking

Why a Chicken Farmer is Like a Corporate Re-Org

A chicken farmer is driving down the road in a truck. All of his chickens are comfortable sitting on their roosts in the back of the truck. They are happy and content in their place. They know the chicken next to them and they quietly cluck away doing their work. (cluck, cluck, cluck ..)

Every now and then, for no apparent reason, the farmer pulls to the side of the road and stops the truck. He walks to the back and opens a door. He gets a baseball bat and bangs on the side of the truck.

BANG BANG BANG

The chickens squawk loudly and fly off their comfortable perches in all directions. Some fly out the door but most of them settle down on a new perch.

Now, the chicken next to them is different. The perch is different. They are uncomfortable and do not know what to make of their new surroundings. There is an uncomfortable clucking noise in the truck that is not as content as it was before. (CLUCK! CLUCK! CLUCK …)

Eventually, the chickens settle down as they get used to their new surroundings. They get used to their new roost and the chickens next to them. After some time, they go back to doing exactly what they were doing before, again content.  (cluck, cluck,cluck…)

Until the next time.

Remember, job security is the skills you have, not the company you work for.

Scaling Agile - What does this even mean?

I have been thinking about this topic for some time. A tweet from @MooneyDev asking for my thoughts on an article written by @jbandi prompted me to write this article.

Mr. Bandi’s article, Why I Don't Believe In Scaling Agile to the Enterprise, makes some very valid points.

I spent the first twenty years of my career as a developer and architect. In the past eight years, I became a delivery manager and project manager. I embraced the points in the Agile Manifesto. I also found the tenets of Extreme Programming, Scrum and Kanban compelling because of their simplicity and came to understand how they can be used to deliver software solutions.

Recently, a popular topic is “how to scale agile”. A number of solutions have been offered, SAFe being one of the more popular solutions. This solution and others have generated some criticism in the development community.

A point often made is that solutions like SAFe are “cashing in” on agile. I agree with this point to some degree. However, this is not new. The IT world is littered with good ideas that have been packaged and sold as solutions.

Another point often mentioned is that agile is mostly common sense and any group of very smart and highly motivated people will succeed using agile. There is no doubt that this is true as well. 

We are asking the wrong question

In my opinion we should not be asking how or if we can scale agile, we should ask how to scale people.

When considering large teams we are facing the bell curve. We need to figure out how to deliver software solutions when hundreds of people are involved. Smart and motivated people would probably be successful with any process. We need to be successful with average folks.

In my opinion, the traditional waterfall approach is not a solution. Pascal Gugenberger wrote an interesting article titled The Waterfall Accident where he points out that Winston W. Royce, the father of the waterfall approach, never intended for it to be a once-and-done, single pass approach.

So, in order to scale people to successfully deliver software, we need to observe the available options around us and carefully select solutions knowing that there is no silver bullet.

SAFe has some attractive options as do other frameworks and approaches. Every firm and situation is different. How do we select the right option?

Open Agile Adoption

I have found the Open Agile Adoption approach offered by Dan Mezick attractive. This approach book-ends a set of iterations with open space meetings. In these meetings, any member of the team is free to post suggested break-out-sessions they feel are important. Attendees are free to attend any meeting they choose. If something is important, folks will attend. 

Every member of the team is invited to attend including executives. This open and free communication enables the team to figure out what is best for them. Typically some flavor of an agile practice is used but the team sorts this out.

These meetings are facilitated by true Servant Leaders who help the team see the path.

I head Dan speak at a user group meeting and I am eager to try his approach on a future engagement. I believe the team knows best the

approach. Leadership is required to help them find the way.

In conclusion

There are firms who have large staffs who need to successfully deliver software. We need to figure out ways for these large firms to be successful. Many approaches have been tried over the decades and we are improving.

The internet has exploded over the years and, clearly, this demonstrates we are learning from our mistakes. I believe that the textbook waterfall methodology is no longer a consideration. Some flavor of agile is. We just need to figure out the details which has always been a challenge.

Agile and Geographically Separate Teams

It is common these days to have delivery teams who are geographically separate. This may occur because offshore resources have been selected for cost saving purposes or simply because teams are split across a region or country.

Scrum calls for co-located teams and the Agile Manifesto embraces face-to-face communication as the most efficient way for teams to communicate. There is no argument with this point. However, when teams are geographically separate, we need to find a compromise.
This article provides techniques for increasing the direct communication for teams who are geographically separate. This includes a mix of technical solutions and meeting logistics.

Be as Face-to-Face as Possible

Coordinate important meetings to include the whole team whenever possible. This approach requires additional costs because travel and lodging are required. Sprint and Release planning meetings benefit from having the whole team in the same room.
If the largest number of people are in a single location with a few other team members in other locations, use the main location for the meeting to save costs.
Schedule happy hour meetings to allow the team to get to know each other and to increase morale.

Use Video Conferencing Equipment

If teams cannot attend meetings in person, use Video Conferencing Equipment. This also has a cost associated with it but the benefit is worth it. This is best utilized when a team member operates a camera at each location. As people talk, the camera is pointed at the speaker. This really improves communication because body language is apparent and people are more likely to participate.
Teams can also collaborate using a whiteboard. Simply point the camera at the board so remote teams can participate.

Rotate Offshore Teams

This approach involves rotating a portion of an offshore team to the project site. For example, a member of the development team from India would spend a period of time onsite with the US team. This approach provides the offshore resource with valuable insight into how the US team operates and allows the remote person to get to know the team.
Later, when the offshore resource returns to India, valuable experience returns with him.
There is definitely additional cost associated with this approach. It is best to decide on this approach before an offshore partner is selected. During price negotiations, this point can be raised. Typically, a blended rate is a solution so the cost of the travel may be accounted for. This blended rate approach usually has a minimal cost effect on the project budget.

Use Technology to Reduce Friction

It is common for agile teams to work together in a shared space. This allows issues to be handled quickly as they come up. Since everyone is in the same room, this is easy. Of course, when teams are split, this is not possible.
Instant Messaging tools like Skype or Lync offer some solutions. Advise the team to Instant Message a person when a question arises. Screen sharing are also available on these tools, so it is almost as easy as huddling around a computer together to collaborate.
These tools also support groups of users. In one of my projects, we setup a DevChat group that the whole team were members of. When any questions arose, they were posted to DevChat. Anyone on the team who had an answer posted it back to the group. It was a very effective communication mechanism.

Keep Scrum Teams Together

When possible, keep scrum teams together as a single unit. For example, if an offshore team is being used to contribute to a project, it is better to have a single scrum team offshore than to split the team between multiple locations. This allows the single scrum team to gain the co-location benefits. 

Time Zones

Different time zones are a major contributor to team friction. When questions arise and some of the team are sleeping, there is an impediment to progress.
An obvious solution is to schedule some overlap hours when the whole team is available. To make this easier, select offshore vendors who are located in regions where the time difference is less of an issue. South America is becoming  a popular offshore region just for that reason.
It is also important to have a local resource on call from the offshore team. This should only be used in an emergency and only if the offshore team will be idle because of some situation.
I have seen times when the whole offshore team was idle for a day because a server needed to be re-booted. A call to the on-call person would have saved a lost day of productivity.


Geographically separate teams do make it more challenging for teams to work together, but it can be done using technology and some structure changes.

Learn More

• How Rally Does Distributed Meetings - There are some very good points in this blog post.
• Logitech Conference Cam - This is a $250 conference solution. 
• Use Skype to Improve Team Communication -  My blog post on using Skype Groups.
• Using an Agile Software Process with Offshore Development - Blog post by Martin Fowler is very good. This should be read by anyone considering offshore teams.

How Rally Does ... Distributed Agile Meetings

How Rally Does ... Distributed Agile Meetings