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.
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.
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?
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?
I have been working with various Agile practices for a few years now and really when full force into Scrum and Kanban at my new position. So, as the coach of the team and assistance to my boss on building an efficient team I decided to study about Scrum practices and take a course.
I attended a ScrumMaster course provided by 3Back which was fantastic! The instructor Dan Rawethorne also published a book which I am reading. The course was full of very useful information and real world experience that Dan participated in through his career. I was lucky to be in a class that had a people that participated a lot which made the class that much better.
The following week I took my ScrumMaster assessment and successfully passed with a 97.1% score! So, I am now a Certified ScrumMaster.
I picked up another book on SCRUM by the same authors as I read and wrote about in this post. I finished “The Elements of Scrum” which is a more thorough exploration of the SCRUM framework. At work we have other departments that follow the SCRUM framework and have a great results. We are moving my group now towards the framework and I am working on implementing our structure of the framework. One of my key take aways from the book is below.
Collaboration between business people and developers should be like voting in Chicago: do it early and do it often!
I have been in the software development industry for well over 15 years now and have been involved i so many aspects of technology. I have seen many many projects slip and complete late and above budget. I have been good at enforcing our timelines in the past, which to be fear means you have to control scope creep. But you also have to have a team that is committed and dedicated to the project. I think this is where SCRUM and agile comes in and helps to make a difference.
A team is a group of skilled individuals functioning in sync to achieve a common goal.
I am moving our team to more of a agile scrum-based structured which is easy in the organization that I work because many of the values of SCRUM are closely aligned with our company’s values. I will be writing more posts as I learn and face various challenges.
Currently, I am schedule for a 2 day workshop with a goal of becoming a Certified Scrum Master by the end of March.
I have been gaining a better understanding of SCRUM lately and read the book “Scrum: a Breathtakingly Brief and Agile Introduction” and just loved the book. After reading through this short and concise book in a day I decided to purchase the more thorough “The Elements of SCRUM” by the same authors.
My notes and highlights (I have more highlights than notes) are available here.
I hope this series of posts on SCRUM and agile are useful, and I am working on building a network of people that also use scrum to further discuss and learn from. I am a believe that we learn constantly and never stop learning.