Agile and Dev Ops Links

Over time I have found a number of useful articles and videos on Agile Practices that I have included in this blog post. 

I have also included some articles I have written that are posted on the Scrum Alliance site. 

I hope you find them useful.

From the Web

• Product Ownership in a Nutshell - Excellent video on Product Ownership and agile delivery in general. We also learn a very useful way to track progress of software projects. This was produced by Henrik Kniberg who has a very creative way of visualizing processes.

• Spotify Culture - Part 1 - This was also created by Henrik Kniberg. He works at Spotify and describes the culture there. Hendrick describes how large teams successfully work together to deliver complex software.  Spotify Culture - Part 2 completes the story.

My Articles

• What Does The Agile Manifesto Mean - This article covers the four main points of the Agile Manifesto and my view of how they relate to the real world.

• The Agile Manifesto Principles - This article continues exploring the Agile Manifesto and covers the twelve principles.

• Scrum is Simple but not Easy - When I was at the Global Scrum Gathering® New Orleans in 2014, they handed out t-shirts that had "Scrum is Simple but not Easy" printed on it. This article explores why we should stick to the tenants of Scrum and what happens when we diverge from them.

My current assignment involves using Dev Ops to a large degree. I have learned that Dev Ops is a logical extension of Agile software delivery. Software has no value until it is in the hands of users and Dev Ops helps do this faster.

• Devops Where do I Start Cheat Sheet - This is a very comprehensive set of links to articles and videos on Dev Ops. It is very Microsoft and Azure focused but will be useful to anyone attempting to understand where to start on this huge topic. I particularly liked the book The Phoenix Project. It is a fun and easy read similar to the One Minute Manager.

• Lead an autonomous DevOps team at Scale: a true story - This presentation was done at the Microsoft Ignite 2016 conference. It describes how Microsoft was able to change from a delivery cycle of every two years to delivery into production every three weeks. 

Best of luck to all of you in your delivery of great software.

Plan and Schedule You Sprint Meetings With This Handy Template

In large corporations, everyone's schedule is packed with meetings. This makes is difficult to schedule the important meetings Scrum needs.

I have created a template that I have been using that is simple and easy.



It includes the name of the project and the sprints contained in a given release. Dates of important activities and meetings are also included.

Once the dates have been established, I schedule All Of The Meetings well in advance. Normally schedules are more open weeks in advance. Once these meetings are on the team's calendar, they schedule other meetings around the existing sprint meetings.

You may access a copy of the template here.

It's Not Your Code

I have worked with a number of teams over the years and from time to time I encounter developers who are very resistant to code reviews. This is normally related to some type of fear.

Some developers are fearful of having mistakes pointed out. This could be because of past experience where the review was painful and took on an accusing tone. Reviewers need to be respectful when reviewing  a set of code. It should be a learning experience that provides value to the developer who's code is being reviewed.

There is also fear that with tight deadlines, the code review will add unnecessary time to an already stress filled schedule. Proper time must be included in the estimation to account for the review. In the end, time will be saved because less bugs will be found.

In rare cases, I have found developers who believe they do not need code reviews because of their experience. We need to point out that a second set of eyes will find things that were missed regardless of experience. Many very experienced developers embrace pair programming, which is in effect a continual code review.

There are some good articles that discuss the code review process.

Jonathan Lange has a nice article, Your Code Sucks and I Hate You where he points about why a code review is necessary and provides some excellent points about how to conduct a proper review.

Esther Schindler makes some excellent points in 5 Reasons for Software Developers to Do Code Reviews (Even If You Think They're a Waste of Time). Point one says that code quality improves simply because developers know their code will be reviewed. This is a perspective I had not thought of myself. There are also useful links in this article that provides tips on conducting a code review.

Daniel Pietraru starts off his article Code Review the Meaningless Ritual be denigrating the process as useless and a wast of time. He concludes with points about how to do a proper review that is focused on value. It is a very good read.

My message to developers is the code you write is not your personal property. It is an asset of the firm you work for and is part of something much bigger than you, a single developer. It is part of a larger product that will change the world in some way.

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.

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

• The Power of Presence
• Power Listening: Mastering the Most Critical Business Skill of All
• The Art of Focused Conversation: 100 Ways to Access Group Wisdom in the Workplace
• The Skilled Facilitator: A Comprehensive Resource for Consultants, Facilitators, Managers, Trainers, and Coaches
• Your Client Isn't Your Product Owner
• Lean UX: Getting Out Of The Deliverables Business
• Lean UX Applying Lean Principles to Improve User Experience

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!

• Keynotes
• Session Slides

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