Being Part of an Agile team

As a technologist I have worked on several different types of teams over my 20+ years of technology development career. Also, as a person I have been involved in different types of groups of people that are working together to solve a common problem or outcome. Several years ago I began a journey with Agile and started working on a Scrum team. I became a Certified Scrum Master and learned from some very intelligent and passionate people who know Agile and Scrum. I have built relationships so I can continue to learn, I believe that you must always continue to learn and never become stagnant.

Today, I wanted to share a blog series that two people that I know and learned from wrote. They have been instrumental in my Agile journey and I am grateful for the knowledge they have shared and continue to share.

Agile seems easy until people get involved.

This quote from the blog series is spot on! Agile does appear very simple, but once you start working on an Agile team with other people it gets difficult. There is confusion, tension and personalities. This must be addressed for any process and Agile has tenants that are geared towards this.

This post is about sharing the series, Agile Leaders, that Russ and Jay wrote, I encourage you to read the series to learn about Agile. I would also like to hear you experiences with Agile. I will be writing more about my thoughts on working in an Agile team and my experiences and frustrations.

I think on of the biggest benefits and struggles of Agile is the short iterations. Delivering something on a short schedule that others can provide feedback on. I say this is a benefit and struggle because first, it is better to identify misunderstandings of requirements early on. Struggles, well anytime you are trying to deliver something complex in a short time, frustration and challenges come to the forefront. Personally, I love challenges, maybe that is why I chose the field I am in.

I would like to hear from you, do you work on an Agile team? What are your thoughts on Agile? How do you apply Agile in other work that is NOT development? I am using Agile to start a non-profit that I am working on and will provide my thoughts as I progress.

Full Disclosure: I work for Russ and Jay at the same company. This post is NOT an affiliate link but just something that I believe in. I do NOT write about anything on this blog that I personally don’t agree with. 

My opinions are my own.


Regular Feedback

Regular Feedback

Regular feedback is a key compont of Agile and also of the values of the company I work for. Feedback needs to be specific, timely and balanced as described in Your First Leadership Job. I believe in this completely, sometimes it is very hard to do. Today, I published a 5 question survey on a high volume site I manage to collect feedback for the future of the site.

I wanted to collect some basic feedback as I prepare to re-launch the site after the 2015 primary election. I am on the ballot for a school director and the re-launch will be themed based on the results of the election. I have been very vocal about transparency and involving the public. Using the survey I can build a score card about the site and hopefully make it better. Afterall, that is really what regular feedback is about, making something better.


Scrum Master Rotation & Metrics Collection

Scrum Master Rotation

My team has implemented a Scrum Master rotation and just finished up the first 2 months of it. We had a retrospective dedicated just to this new process and had a lot of great feedback from it.

I found that it provided a whole different perspective on what we do and how we understand Scrum. But, I found that this also helped really protect the sprint with this rotation, we decided to make he rotation last 3 months and extended the current person another month. We also selected the next person that will take the duties of Scrum Master.

Metrics Collection

As part of this rotation we have started to break down our stories into tasks better, well actually to doing it. We haven’t been breaking them down to the  task level. I am one that likes to keep the stories very small which could make it harder for tasks, but love the idea of having the tasks written and thought it. It provide much better understanding of the story and helps with commitments that are made.

When breaking down our stories we are not trying to estimate hours on the tasks and log hours against the tasks for daily tracking. This is now looked at during daily stand up meetings. The idea is that we can learn more about our points by looking at the actual hours that it takes to do the work. Also, it the metrics could be used to show resource gaps that we have.

Do you collect metrics other than story points during your sprints? Do you use them in your daily stand-ups? How do you break tasks down. I would love to hear from you how how your scrum works. Have you ever rotated the Scrum Master role?

My First Try at Speaking

My First Try at Speaking

Well, not really my first try, but my first really public speaking. I find it funny and like to bring it up that when I was in school I would NOT speak in front of the class, I would take a failing grade instead of speaking. Now, I am facilitating meetings and talking in front of groups all of the time.

But, this past week was something completely new and I was very excited about it. I had the opportunity to speak for Baldwin-Whitehall School District’s Personal Development day which was focused on technology.  Then the very next day I spoke at a #PittAgile meetup. I was very excited about both and had very little nervousness, which in retrospective may have been one of the problems.

Below is a list of the talks:

The first two talks where for Baldwin-Whitehall School District, the third talk was for the PittAgile community group. I started by preparing for these talks as speeches which I had some experience with over the past year. My “speeches” where limited to 3 minutes during the year; this time I had a full 50 minutes to talk and present to an audience, which is vastly different. I found that starting as a speech was very helping, I just open up and starting typing like I was going to talk. First, I needed to have a short paragraph to be used for a description of my talks, this would be taken from my writing.

I followed typically writing practices with a 1st draft, editing, 2nd draft, and final draft. After I had my words ready, I then started to look for how I can present this information in the form of slides. I searched for images using Flickr, filtering for creative commons. I took my words from the speech document and placed them in the corresponding notes for each slide. There, I had my finished presentation completed and ready. I wish it was that simple, the process is simple, but doing this took time. A lot of time to think and process my thoughts. To edit and research. I like to research what I am going to talk about and also get feedback from others. I did not intend to read the notes, I just want to practice the “speech” so that I could have my content ready and be ready to adapt when in front of the audience.

Following a standard concept for Agile, I wanted to get feedback to learn and adapt. One of my mentors used a technique that I really liked so I used that for collecting feedback.

I handed out PostIts and pens so that I could collect feedback. Before even starting my talk I explained that I wanted to get feedback on my talk and that I wanted to learn. I also told my audience that I am not looking for bashing, to please keep that in mind and help me learn more.

On flip chart paper I made four quadrants as you can see to the left, with the following text.

  1. Good talk
  2. Good but could improve
  3. Not very good
  4. Come talk to my team

I told the audience to write on the PostIts their feedback for me to learn from. Agile is about adapting and a key to adapting is learning to accept feedback from others. So, I asked them to please help me improve by writing their thoughts and place the PostIt on the appropriate section on the flip chart.


I did this during my first two talks and failed to do this at my final talk;  when really I needed the most feedback. My first two received a lot of good feedback. I heard that I should have provided more hands on work during my talk about Evernote. Also, I learned that I should have requested more time for both of those sessions. Great information and this feedback will help me do better next time.

My final session was my lessons learned on facilitating my first innovation week for my team. This was a difficult one to prepare for, I started the talk with the value of innovation weeks and also some examples of other organizations that have innovation time.

My biggest problem was I didn’t go into enough detail on the concrete examples of how we performed our innovation time and the exact outcomes of our innovation week. This time was very valuable and our team was able to help our projects out a lot. I could have went into more detail about that.

What happened was my time fell short and I went through my material a lot faster than I had expected. The audiences between the talks where different and resulting in different timings that I needed. Where the first two I could have used more time the third I had trouble filling my required time. I ended up adapting though and changing the talk into an open dialog with the audience, since I had a small audience, about 10 people this worked out well. Had I had a larger audience this would have not been possible.

So, for my next talk I will:

  1. Think more about who my audience is
  2. Provide more specific examples that focus on my message
  3. Provide hands on activities if I am talking on software and in a lab
  4. Continue to use the same feedback method discussed above
  5. Continue my approach of starting as a speech

Potentially Shippable

As I continue my studies of Scrum I continue to a road block on the idea of “potentially shippable” at the end of each sprint.

Incremental deliveries of “Done” product ensure a potentially useful version of
working product is always available.

My confusion is always centered around the initial sprint where the idea of the product is just an idea and there is nothing available to build upon. As I think through the process I have trouble seeing how a potentially shippable product can be demonstrated on the first sprint when there was absolutely nothing previously. Future version, I can see working more easily, but the first version of a product when there is so much to do I have trouble grasping.

I am going to put my thoughts together in this post and hope to get some comments and feedback to help me and whoever else finds this post understand this better.

A stake holder has an idea for a product and a business owner is selected, the business owner then works with a Product Owner to help clarify the idea. A team is assembled to do the work, consisting of various members including a Scrum Master.

There are several ideas that the business owner wants and talked out with the product owner, but the PO prioritizes the stories in a list and the team can then choose what to work on for the first sprint. But, there are things that must be done first that do NOT deliver anything that would be potentially shippable to the BO. It may consist of just a security framework or navigation system, or just a look-n-feel (workable wire frame). This is where my confusion sets in, this is not potentially shippable, I guess it could be but it would be of no value to the stake holders as this point.

So, my fellow Agilists, what are your thoughts on this?