Team Expiration

There has been a lot written about the needs and benefits of keeping a team stable in the Agile community. As we see how software development is more of a team sport, we spend time and effort in trying to get the team to function better as a team.

But, when we look at team sports, e.g. the NFL, NBA why is it that they don’t seem to have the same players for long?

I think that there is an expiration date to a team. There is going to come a time when we need to make changes to a team in order to raise the bar.

With that in mind, I brought it to Charles. Check out our conversation:-

Part 1

Part 2

 

What are your thoughts?

New adventures off to a fun start.

My new venture into the world of YouTube has been awesome. I have learn a lot about how to do recording, editing, lighting, sound and video.

One of the things that I wanted to do is to capture the conversation that I have had with Charles Rodriguez. Often times, I walk away from the conversation with more learnings and always wish that I could share it with others.

Fortunately, my new ventures have allow me to do that.

So check out the recordings that we have made.

 

 

Opportunity to fail

Recently, I had an opportunity to fail. I had the craziest idea that I can do a video coverage of this year’s TriAgile 2017 conference. It is a local conference and one of the best in my opinion for the Triangle area. This will be my third one.

What is crazy about this is that, I have zero experience doing something like this. I cannot even pronounce the word – ‘vlogging’. 🙂 And…. I am an introvert.

I did some online research on tips, tricks and equipment and figured out that I don’t have the right equipment but it could be done. So arm with my iPhone 5s and a mic for the iPhone which I bought 2 days before the conference, I set forth.

The result is that I learned a lot about what works and what did not, how to use the tools, how to plan and so much more. My skills got better throughout the day, and by the end of the day, I know I had walk away with more knowledge than I had when I walked in.

Growth and learning happens the most when we don’t know and when we are not comfortable.

Here is the final result: TriAgile 2017 Coverage.

Thank you to the folks at TriAgile and to the ones that was willing to talk to my phone. 🙂

 

Into the unknown

Recently, Peter Saddington, my CSM trainer embarked on a life experiment. Check out why he is doing this and what it is about at First15.tv . I think it is an awesome thing to do.

His idea of sharing what he learned got me thinking. What if?

I have had the thoughts of doing podcast similar to the Meta-Cast before but Peter changed my mind. What the heck. Go big or go home.

So I created my own YouTube channel. I have zero knowledge before this and in the last 2 weeks, I have learned so much.

Check it out. Introducing MasterAsianKhor. I will be posting my thoughts and ideas in the hope to help others as they go thru their journey. Subscribe.

Looking forward to engaging with you and learning from your feedback.

Feedback, feedback, feedback everywhere.

Pick up a cup of coffee. With a touch of the cup, we can tell if the coffee is hot, warm or cold. We then take a sip. Our lips tell us if it is too hot or too cold or is it just right.

What would happen if there is a delay in the feedback? You pick up the cup and it takes you a while to figure out if it is hot, warm or cold.

What would happen if you pick up the cup and you don’t know? No feedback is also a form of feedback.

Our decision to drink a cup of coffee is based on multiple feedbacks. Drinking the coffee is a response to the feedbacks.

It is no different in software development.

For a developer, feedback is not just the result writing a piece of code. It is not just the result from QA. It is not just from users using our product. It is more than that. Feedback also includes how business/executives/management respond to the work that was delivered.

Agile is all about feedback. Read thru the values and principles of Agile Manifesto. What do you see? I see feedback written all over it. Improving feedback, direct feedback, increase feedback, reducing the feedback loop and responding to feedback. It is all about feedback.

Let’s look at some of them.

Individuals and interactions over process and tools	Improving feedback
Working software over comprehensive documentation	Improving feedback
Customer collaboration over contract negotiation	Improving feedback Direct feedback
Responding to change over following a plan	Increasing feedback Getting feedback
Deliver software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.	Reducing feedback loop. Increasing feedback.
Business people and developers must work together daily throughout the project.	Improving feedback. Direct feedback. Increase feedback.
Working software is the primary measure of progress.	Direct feedback
At regular intervals, the team reflects on how to become more effective, then tunes and adjust its behavior accordingly.	Get feedback and respond to feedback.

Regardless if you like Agile or not, there is no denying that feedback and our response to feedback determines the outcome.

So if we want a better outcome, we should be putting our effort in getting feedback, improving feedback, increasing feedback, and responding to the feedback.

CSM Certification is not for the everyone.

The CSM certification can and does help those that wants to become a Scrum Master. However, I see that the use of the certification class have diluted the value of the certification. I see a lot of those that are attending the certification class, are there, not to be a Scrum Master but they are there to get an introduction to Agile and Scrum. I know that we can’t control who attend the class, but as agile evangelist, coach and trainer, we have the responsibility to provide the right tool for the right problem.

If you want to be a Scrum Master, then by all means you should get certified as one. Certification does not guarantee success as a Scrum Master, but it is a step towards being a better Scrum Master.

If you are looking to see if Agile or Scrum is right for your organization, then you should be talking to a coach. Taking the CSM class does not help you get the answer that you are looking for. Seek out introductory courses to Agile. Have a conversation with an Agile Coach. Or seek out the agile community in your area. There are many of us that will be more than happy to share our experience with you.

I truly believe that all of us in the agile community have the right intention but sometimes the implementation may not be right. Most trainers are good people and they want to help those that want to adopt Agile. Trainers, it is your responsibility to do the right thing.

So, let’s all do our part to help those that wants to be agile.

Agile Charlatan

I do not claim to be an expert in Agile. I am on my way to find better ways to doing software and in my process I have come across many individuals and blogs. With the ease of sharing contents, I have come across those that are helpful and those that I feel that are harmful.

I categorize them into 3 different types:-

1. Those that have been there and done that and are now sharing their experiences.
2. Those who are in the process of doing it and learning and sharing what they have learn.
3. Those who thinks they know Agile but have no experience whatsoever and sharing as if they are the expert.

Category 3 is the one that I find harmful to the community. They are self-proclaim expert and tend to use big words in their blogs and conversations. I am sure you have met one or two in your career and journey.

Below are my rants and some of the disturbing things that I recently come across.

1. Having an innovation squad does not make an organization become innovative. Innovation cannot be contained and forced. Innovation happens when it wants to happen.
2. One of the value of Agile Manifesto is to deliver working software. Working software means it has been tested and ready for production. Delivering a piece of software that is not production ready and have not been tested is not the goal. Handing off software from one group to the next in order to get it to production is not Agile. If your process of delivering software is multiple steps, to get from design to production, then you are practicing waterfall. Sugar coating it with different name or using big words to justify it does not make it Agile.
3. Those that claim to be Agile just so that they can sell you services.

As you continue your education in Agile and in finding better ways of doing software, I urge you to be on the lookout for these and if you see them or encounter them, I highly urge you turn around and run.

Metrics? What Metrics?

As an agile shop, we are constantly asked what metrics we track. My answer is that we don’t. What?

We do have health indicators that we keep an eye on. I see indicators and metrics as different things. Metric is a comparison against some number and based on that comparison it is good or bad. Indicators shows a specific state. The readings from indicators are just readings for that specific time.

Similar to the gauges in a plane, our indicators provide information that we use to make corrections and improvements. For example, the altimeter tells the pilot the altitude of the plane. If the altitude is showing a very low number, it could be good or bad depending on what the plane is doing. It could be parked or it could be about to land, so we expect the altitude to drop. And that is okay. The pilot uses a lot of gauges and instruments similar to the altimeter to help fly the plane.

Similar to the pilot, we use these health indicators to enable the team to achieve high performance. Depending on the team, the indicators have different meaning and they are not meant to be used to compare one team against another. They are also not meant to measure individual performance. The information gathered is meant as the starting point for further conversations that leads to discoveries, understandings and potential changes.

Below are the indicators that we use:-

Burndown History

Once a quarter, we will look at the last 8 burndown charts. We look for common trends among the 8 charts.

• Are there a lot of cliffs? i.e. Are we closing stories only at the end of the sprint?
• Are there a lot of work pull in at the end of the sprint? i.e. Are we pulling in the correct amount of work?
• Are there new work introduce into the sprint? Constant interruption?
• Are we swarming enough?
• Are we silo in how we work?

Committed Points vs Completed Points

We collect the number of points committed at the beginning of the sprint and the number of points that was completed at the end of the sprint. We see if there are trends to how many times a squad under commit or over commit. Indicators or discussion points from these data, are:

• Does the team have a fear of failure?
• Are we under committing? Or over committing?
• Are team stretching themselves so that they can be better? What is the percentage of times did the team completed everything that they commited to?

Team Velocity Trends

We look at the velocity trends to see if the squads are moving in the right direction. Overall, we expect to see squad increasing their velocity over time.

• Is there a drop in velocity? Why?
• Is there a gain in velocity? Why?
• Are we inflating the story points?
• Does the curve makes sense?

360 Individual Feedback

At a quarterly interval we send out 360 feedback to everyone in the tribe. Individuals are asked to provide feedback on squad members and also those that work closely with them. We ask the individuals to rate how the person they work measures up against our values. The collective data allows us to see if the squad is aligning with our values. This data also allows us to reflect on where the squad has been and areas where there may be potential improvement.

Team Health

Another survey that we send out is about the team health. In this survey, we ask individuals to rate how the Scrum ceremonies are running and how each of the supporting roles (managers, product owners, scrummasters, etc.) and channels (chapters) are working for the team. The data allows us to reflect on where we can improve and help with improvement for supporting roles and channels.

Points Per Person Per Sprint

The most controversial data that we collect, is the number of points per person per sprint. These data points helps us reflect on the trends similar to velocity.

• What can we do to improve?
• Is there an upward trend or downward trend?
• What causes these trending?

What do we do with these indicators? We share the data with each individual team and facilitate conversations and discussions on what does each one of these indicator could potentially mean.

The basis for all of these indicators is that each tells a story. These gives us some insight into what happen in the past. We look at them and as a team figure out what we can tweak or change so that we can get better.

Agile Donut @ Dude Solutions Technology Day Feb 20th 2016

It is very uncomfortable for me to watch a recording of my presentations. Most of the time, I would not remember what I said.  But, the opportunity to reflect on it and be transparent about myself, about my strengths and weakness, about how I can be better at doing presentations does not always present itself. And surprising enough, in the journey to bring my presentations to the outside world, it allows me to learn to use WavePad, VideoPad and Open Broadcaster Software.

Here is the presentation: http://bit.ly/1Riu0hS

Have fun.

We use physical board for Scrum.

Why should we use a physical board? It is a waste of time. No values. We should use [XYZ] tool only. Why should we duplicate what is already in [XYZ] tool? Its not Scrum that’s Kanban. Online or virtual tool is so much easier.

These are the questions, comments and countless more, that I hear regularly from team members, developers and management alike when I suggest the use of a physical board for a Scrum team.

So, why do we use a physical board? Good question. 🙂

At Dude Solutions, we use Jira which is our system of record and each team have a physical board.

Here’s why we use the physical board:-

1. Visualization of work. Yes, this is the same as Kanban. The visualization helps teams, that are new to Scrum, to see the flow of work.
2. Team focus. The board is easily accessible to everyone on the team, thus allowing any team member to know the work they have signed up for and how the sprint is going. How many stories is closed? Which story is blocked?
3. Sequence of work. Team members can easily identify in what order they should complete the work. Or which one they should combine their effort on. Or which one to do next.
4. Sprint Goal. Team members mark the anchor stories for the sprint on the stickies. This allows teams to focus on the ones that helps them obtain the sprint goal.
5. Tries. Teams can write down the things that they are going to try for the sprint. This helps teams to remember what their action items are from their retrospective.
6. Celebration. We celebrate when a story is completed. This is a great motivation and encouragement for teams to close stories.
7. Help with daily stand-up.  The concept of ‘walking the board’ or ‘talking to the board’ works well if you have a board that the team can reference. This helps teams to do their stand-up easily.
8. Conversation focal point. Often times, teams will congregate in front of the board when they discuss work. The board allows teams to carry conversation about the work easily.
9. Transparency. Since the board is in a location that is visible to anyone that walks by, this promotes transparency.

My thoughts…

If the physical board is only a duplication of another tool then the team is right. It has not value.

The board should be simple. It should have value to the team. It should be able to show and do all of the above. It should not be a duplicate of Jira board. The amount of effort in maintaining the separate board is minimal compare to the values that it provides.

What about distributed teams?

This will depend on the composition of the teams and what makes sense. I have seen different implementation of it. Some take pictures at the end of the daily stand-up. Some have camera’s pointing to the physical board.

What if everyone is remote and there is no possible way for a physical board? Can’t we simulate a physical board virtually? Check out Realtimeboard.com. I don’t think there is anything wrong with having a separate board online. If it is simple and can provide all of the values above, I say go for it.