Saturday, November 22, 2014

The Power of Scrum - The Backlog and Product Owner

The more I work with teams and use Scrum to deliver software solutions, the more impressed I am with the simplicity and power of Scrum. I thought I would take some time to blog about some of the more powerful points. I will start with the Backlog and Product Owner.

Build the Right Thing

In this competitive world, one of the major risks we face is, are we building the right thing? This has two important aspects to it.
On one hand, are we including the most important features for our product? If we miss an important feature, we may miss a competitive opportunity and lose market share. Our competitors may beat us to the punch.
Or perhaps we are building many features, but not the ones that really add value. We could be very efficient, and deliver features on time and within budget. However, if these features are things our customers do not need, it has been a waste.

The Product Owner

Scrum has a role that focuses specifically on this challenge. The Product Owner is the person who understands the Product being delivered better than anyone. She understands the competitive marketplace and understands what features are important for the Product. These features are maintained in a prioritized list known as the Product Backlog.

The Product Backlog

The backlog is fluid and changes often. As the Product Owner conducts surveys and interviews stake holders, the features on the backlog and their priority change.
This sets Scrum apart from more traditional development approaches where we define what we need up front and consider most changes as an unwelcome event. Scrum embraces change and accommodates it as a core principle.

Stop at Any Time

Since the backlog is prioritized, the most important and valuable features are at the top. This means as we move down the backlog delivering features that are a bit less valuable than the previous ones, we can stop at any time.
When we have delivered enough value, what ever that is, we can stop. This also sets Scrum apart. Under more traditional delivery approaches, we deliver everything we defined at the beginning of the project, even if a feature is rarely used.

Sprints

The Team delivers features from the top of the backlog in a series of short cycles called sprints. My next post will discuss the power of this technique.

Sunday, June 8, 2014

Global SCRUM GATHERING® New Orleans 2014 - The Scrum Master

This is the final article about some important points I took away 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 first article pertained to The Team while the second focused on The Product. This article will discuss the Scrum Master.

The Scrum Master

It was very interesting to see a large number of people who are experienced Scrum Masters. Each of these people brought their experience to the sessions I attended.
A common theme was to show respect whenever you are talking to the team or individuals and be wary of your body language as you interact. It is very easy in the heat of the moment to become emotional.
It is important to remember that the Scrum Master has no decision making authority. This is actually a powerful position because it focuses decisions on the team who after all are the experts.
A scrum master should become the Master of the Question and facilitate Fact Based Discussions. It is also critical to remember to ask the team as issues and decisions need to be made. 
I attended a session that focused on listening. Some important points we discussed were:
  • Maintain eye contact as you talk to a person. Watch their body language as you interact with them.
  • The person you are talking to is the most important person in the world at that time. 
  • Pocket the phone when you talk. Do not check emails or answer a call unless it is an emergency.  If you must take a call excuse yourself with a statement like “I am sorry, this is my daughter, it may be an emergency”.
  • Re-state what the person said so you can validate your understanding of the conversation.
  • Write down the person’s name if you are new to a team, it will help you remember them in the future.
A number of people mentioned that they use a Scrum Master Checklist as a way to stay on track. This checklist asks questions about the backlog, user stories, and other important points that help keep a project on track. I have created a checklist in Excel that I plan to use from now on. If you want to check it out, it is available here.
One of the more creative sessions was titled Coaching Like Columbo by Dr. Patrick McConnell of CSC. The premise of this session was to:
  • Ask a very simple, non-confrontational question focused on outcomes or daily experience.
  • Shut up, for a while.
  • Start connecting the dots backward to choices.
We used the diagram below ask questions and broke off into teams.


Our team had to answer the question:
How did your last release go?
For the Un Healthy answer we Came up with:
The release was late, someone died and our company’s stock price went down.
For the healthy answer we came up with:
We released more than planned on time, the product won an award and we became rich because of our stock options.
We then worked on the conditions for each of our answers. This light hearted approach was fun and a method to uncover creative answers. I plan to use this on some of my future projects.
I was very happy with the outcome of the conference. I would recommend it to every agile practitioner.

Learn More 

Vendor / Content

  • Visual AGILExicon – This was developed by Ken Rubin who wrote a very popular book and has trained thousands of people. This AGILExicon Visual Agile Lexicon  is a set of re-useable graphically rich diagrams that cover the concepts of Scrum. It is available to all for free to use.
  • Axosoft - Axosoft is a vendor who sells a suite of agile tools. The bug tracker tool is available for $1 per year for teams of any size.
  • Cisco Products - This is a set of high end tele-presence products for geographically separate teams.
  • Sococo Products - virtual office software for geographically separate teams. Virtual offices, chat and meeting rooms keep teams together.

Books / Articles

Conference Slides and Keynotes  

These links provide access to the session slides and keynote presentations. You have to be a member of the Scrum Alliance but after that, the content is free. I highly recommend The Business Value of Joy, Richard Sheridan. It got a standing ovation and is excellent!


Sunday, May 18, 2014

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.




Sunday, May 11, 2014

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





Saturday, April 12, 2014

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

Thursday, April 3, 2014

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.

Sunday, February 16, 2014

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.