Ratings!

Hello!
I am really hoping to get some feedback on the blog. Comments are more than welcome, but I've also coded up a small ratings gadget and added it to each of my blog posts.

Please rate the post to tell me if you like it or hate it!

Thanks a ton!
Amol

Rate this post!

☆

☆

☆

☆

☆

Story Estimation - sizing and splitting

I have found that a lot of people have problems with sizing / estimation meetings, so here are some thoughts on that topic. Let's start by defining Story Points - the unit of estimation. To put simply - story points are a measure work effort. We use units of work effort to derive time. 

Why estimate?

In my opinion, the greatest need for estimation primarily arises from the need for release planning.  Most teams I have worked with work on some sort of a plan for releasing their software to the users. Estimates can provide data about how you are doing with reference to your plan.

Not everyone may need estimates though. If you are experienced in Agile, consider giving up estimates for a release or two. However, if you are starting out on Agile, I recommend starting on the side of having estimates. 

Sizing defects?

In my opinion, if a defect must be fixed for the release to go out, it doesn’t matter if you estimate it or not. If you are want to gauge how many low / medium priority defects you can fix in a given time frame, it may make sense to put sizes on them.

Defects can be notoriously hard to size, so time-box the sizing activity. 

Now that we've covered the basics, lets talk a bit about what the Scrum Master needs to do in order to have a successful sizing meeting.

Coaching the product owner on Minimum Viable Product:

I think this image is a perfect example of Minimum Viable Product. I'll let you think about what it is saying. All I can say is that I'm a big proponent of starting out by trying to build stakeboards, not spaceships. Coach your product owners to do the same.

I came across this example from the wonderful podcast at - This Agile Life

Coaching the team to embrace unclear requirements:

At the outset of a project, I tell my team the following 2 points: 

• Inspiration does not come in the form of a prioritized backlog. 
• You don't really know the full potential of your product until you've built it. 

An example of product potential is - I feel confident in saying that Twitter didn't start out trying to build a tool to overthrow dictators. Most products aren't used the way they are initially defined. This makes the product definition job a really hard one. When building a new product, there is no right or wrong answer. This is a wonderful reason to embrace Agile. It is the job of the team to shape unclear product requirements / stories and help build small increments of functionality. Sizing aids that process. Don't shy away from it, even though it can sometimes be painful.

Mechanics of sizing and splitting meeting:

Reference Story(s):

I recommend defining at least one, possibly 2-3 standard / reference user stories. User stories in the product backlog should be estimated based on these reference stories. A reference user story can be story that is fairly well understood by everyone in the team. A story that is already implemented by the team can be a good candidate reference story. It is best if it touches all the layers - UI, business logic, database / server.

Some points that aid sizing / estimation meetings

I've been a part of teams where team members cannot take their engineering hats off when putting a number on the story. For whatever reason, they are scared to put numbers on user stories. I call this "everything-is-a-5" syndrome. I use an Earth vs Sun example to try to overcome this. Even though the Earth is much smaller than the Sun, it doesn't mean there is no work involved in building Earth. It is just that it is less compared to building the Sun. So Earth and Sun can't both be sized to 5.

Sizing  based on "what?" and not "how?"  

I encourage the team to size based on the “what?” and now the “how?” Let's take an example: Let’s say our reference story is one where - we top off the coolant in a car. The story we need to size is say - changing brake fluid.  

I have seen teams get stuck in discussing the implementation details of the brake fluid user story. This has the potential to make sizing meeting remarkably painful. To overcome this, I explain to the team that the question "what?" should yield the size of the story, while the question "how?" is solved in the sprint itself. 

To help aid sizing based on "what?", I encourage teams to try to take a step back and understand what we are changing / touching with the story being sized. Once that is clear, I compare and contrast the story being sized with the reference story. 

For our brake fluid story story, I can say that the car will have some sort of a container holding the brake fluid, just like the coolant container in the reference story. The reference story only involves topping off the coolant container, while the brake fluid story is about changing the fluid. Based on this information, we can say that the brake fluid story is bigger than reference coolant story. This level of detail is generally enough to put sizes / estimates on stories. 

I find that using this technique has yielded reasonably quick and usable estimates. 

In addition to the points above, I found this article by Mike Cohn really helpful to have an "Estimation 101" workshop with my team.

Rate this post!

☆

☆

☆

☆

☆

Continuous improvement

Continuous improvement is an important part of being Agile. There are several aspects of continuous improvement, I'd like to discuss them one by one.

Continuous product improvement

There is no such things as a perfect product. The idea behind Agile is to keep making improvements to the product by continuously delivering updated working versions to your end users. 

The end users, who are represented by the product owner usually will keep adding items to the backlog, which a Scrum team burns through. This cycle helps deliver a continuously improving product to the customer.

I recently worked on an app where the user ratings were dismal when we took over the work. We invested time to understand the greatest needs of our customers and made small but quick improvements in those areas. We delivered each improvement to customer as soon as it was ready. Instead of waiting for several big features to be ready, which could potentially have taken months, we resorted to doing small changes in the areas that were most needed. By the time we focused our attention away from the project, we had increased the user ratings by about 75%. 

It is commonplace to see app updates and website updates very frequently these days. It can however be quite tough for teams to achieve. I am a big advocate of 'not sitting on ready features' however small they may be, but to let the customers have it as quickly as possible.

Continuous process improvement

At the end of every sprint, it is essential that teams meet for a short while to discuss what went well and what didn't go so well. This is done in a Scrum retrospective meeting. It is important for Scrum Masters to create a safe environment where everyone feels empowered to raise concerns and discuss issues. There are 5 stages to a good retrospective - Setting the stage, Gather Data, Generate Insights, Decide what to do, and Closing. It is only by having good retrospectives that continuous process improvement can be achieved. 

I have 2 quick recommendations for Scrum Masters as their team decides how to tweak their processes:

1. I recommend reading this short article - Shu Ha Ri by Martin Fowler. In the article, the author compares talks about various stages of knowledge that a team is in. It is important that you make sure your team follows the rules depending on your team's stage of Scrum knowledge.
2. If your team has gotten in a groove where they work well with the current set of processes, I believe it is the Scrum Master's responsibility to try and poke the team into experimentation. You learn best by experimenting, so don't be afraid to do that. The worst thing that you can do is to limit yourself by sticking to a set of rigid rules. This is the last knowledge stage discussed in the article above.

Continuous self (and team) improvement

Just like products and processes, there is no such things as a perfect teams. It is important to think about how you can improve yourself and your team continuously in order to achieve excellence. Persistence is the key to success. In the book - Outliers, Malcom Gladwell talks about the 10,000-hour rule in order to achieve success and excellence. Slow and steady but continuous self improvement is crucial to success. Remember, it takes time for teams to figure out how to work with each other. However, when a team gets over that stage, it can make progress quite quickly. I believe in investing that time in a team to give them a chance to excel.

Rate this post!

☆

☆

☆

☆

☆

Servant Leadership in Scrum context

Servant leadership is a very interesting and complicated topic to think and write about. Here is a stab at servant leadership in Scrum context as I understand and experience it. I plan to write more on the topic as I continue my research. I'm particularly interested in getting at some sort of a measure or scale for various aspects of Servant Leadership I characterize below.

Servant Leadership was first introduced as a theory by Robert Greenleaf in an essay published in 1970. You can read more about it at: What is Servant Leadership

I absolutely loved this TED talk - Lead like the great conductors. I think the speaker has talked about several traits of a servant leader extremely well there.

Here are a few aspects of a servant leadership:

1. Trust, Integrity and Honesty
2. Influence
3. Service
4. Vision
5. Putting others first

Lets's talk about them one by one.

A Scrum Master usually does not have direct authority over the team he or she is working with. This usually means that the Scrum Master needs to earn and keep the trust of the team members in order to effectively lead them. You cannot really gain trust from anyone overnight. A few ways to start on the path of gaining trust are to be honest and open in communication with the team; give them appropriate feedback - good or bad as and when necessary; truly listening to the team's feedback with an open mind, and implementing the suggestions they provide. I mentioned in my article about Scrum - metrics that it is important to keep track of the right set of data points in order to build an environment where the team trusts each other and the Scrum Master. 

As Itay Talgam said in the TED talk above, a leader is responsible not only for creating a process but also for creating the conditions in the world where the process will be successful. It is extremely important for a Scrum Master to have the ability to influence people in order to create these conditions in the world. I find that engaging people in conversations is a good way to create lasting influence. Rather than commanding and directing people, asking good questions, showing empathy and listening to their answers with an open mind is a good way to engage people in real conversations and exercise influence. I recently heard an episode of This American Life, which I thought was very relevant to this topic.

Next important quality is the attitude of a servant that Scrum Master needs to exhibit. It is the Scrum Masters that serve their team, and not the other way around. I believe there are 2 aspects of service. The first is to do what the team asks you to do. A couple of examples here can be - taking out the trash for the team, or making sure they have appropriate equipment to do their work etc. The second type of service that a Scrum Master provides their team is influencing other people in the organization to create the conditions for the team to be successful. However, it is important to note that the Scrum Master should not lose sight of their job to bring the team back on track, if needed with appropriate authority, while they are serving their team.

Vision is an important quality for any leader to have. A Scrum Master is responsible for looking at the forest for the trees. Since the SM maintains the data points for the team, they are the first to know where the ship is headed. The SM needs to use this vantage point to have a vision - for both - the process and project / intended solution to help guide the team and the PO appropriately.

Building a team that functions well involves giving real power to the team. Giving power to people involves putting the team's interest first. A good Scrum Master has a team oriented personality. They empower people rather than give permission. They help their team grow and succeed the best way they know how.  In doing so, they build a community of people that come to rely on, provide for and trust each other. All this can only be achieved by giving priority to the people and their needs. I believe the last video that Itay Talgram showed in the TED talk linked above is an excellent example of this.

Rate this post!

☆

☆

☆

☆

☆

My first Android App!

Recently my wife took up a job in Minneapolis, so she had to study for Minnesota DMV test. She collected a bunch of questions, and I built an Android app for folks to study for the test.

The app is available for free on Amazon App Store:

MN DMV Questions

We'd love to hear your feedback!

The source for the app can be found on my GitHub page:
GitHub/bapatamol

Rate this post!

☆

☆

☆

☆

☆

Stand-up meetings

Scrum 101

A stand-up meeting is a place for a Scrum team to discuss progress made on sprint commitments. It is usually a short meeting, typically about 15 minutes and under.

A good stand-up helps answer the following 3 questions:

• What did I accomplish yesterday?
• What am I planning to accomplish today?
• Are there any impediments in my way?

It is a good practice to have a stand-up meeting every day of the sprint. 

Stand-up meetings are meetings where the team exchanges information, and isn't a status meeting. Scrum Masters should promote information sharing in the meeting. It is a sign of a good Scrum team if people say "hey! I had run into that a couple of days ago, and I can tell you what I did to get over it" or "I'm running into the same issue, but I've developed this workaround".

Rationale for the theory

After a team has made commitments for a sprint, they need a time and place to get together and share what they have learned and where they are in terms of meeting their commitments. Stand-ups serve that purpose. They are supposed to be quick meetings, where folks share information with each other and go back to their normal work-day. 

When stories are written in such a way that promote swarming, stand-up meetings are truly helpful. With well written stories, stand-ups can help promote peer pressure. 

Tips & Tricks

Scrum Masters should come prepared to the stand-up meeting. This preparation involves trying to predict what each team member will say, and in that way you can listen for what is not being said.

Ask your team to really stand-up in the stand-up meeting, especially if the meeting usually runs longer than 15 minutes.

Here are tricks to detect if your stand-up meetings have become status meetings:

• Folks have tuned out and are looking at their phones when someone is talking.
• The person who is talking is looking at the Scrum Master and not his / her team mates
• Only a handful of people present in the room, say Scrum Master, 'dev lead', 'test lead', etc. understand what is being said by a person. 
• Not everyone present in the stand-up fully understands the impact of an issue being raised by someone.

If you have team-mates who are remote, it may be a good idea to have a video conference set-up. If you have multiple remote sites, you can alternate between them showing one site one day and next site the next day. That helps team members gel together and they are more likely to contact each other throughout the workday.

If your work-place does not have any information radiators, it may be a good idea to show some sort of a sprint metric - possibly a burn down chart to all the team members in the stand-up meeting.

A good idea for keeping stand-ups short and relevant is to have the right people involved in the meeting. If there is stroing 'management oversight', teams may not be willing to discuss real issues. It is important for Scrum Masters to keep the meetings short and only have relevant people invited to the meeting. Work status and any heat because of that can be done offline.

If you have a team member hogging the time in a stand-up meeting, it is a good idea for Scrum Masters to let the team auto-correct the behavior. This can be done by the team in the meeting itself, or in a retrospective.

It is important that folks talk about sprint commitments in the stand-up meeting. If your team has roles like an architect or dev-lead, test-lead etc. they may share information they learned the previous day that is relevant to the team's efforts. It doesn't make sense for a manager who listens in on a meeting to share what he/she did yesterday, because that is not necessarily relevant to the team's commitments.

Rate this post!

☆

☆

☆

☆

☆

My web projects

I had a couple of weeks off, so I decided to resurrect some of my old web projects.

YAWN - Yet Another Web Network
I had taken some time to develop a social networking app with JQuery Ajax / PHP. I really liked the small PHP-service based design for the app.

Here is the implementation: YAWN
Here is the source code: yawn.git

Chats
Chats is a web based chat project. The idea here is on each onKeyUp event in an HTML text area, update a table and show the contents in a HTML / span. You can use this to write messages to friends, or use as an instant HTML renderer.

Here is the implementation: Chats
Here is the source code: chats.git

The websites are hosted for free, so are the MySQL databases. Please don't enter any personal / identifiable information in those databases.

I'd love to hear some feedback / comments on the code from you guys!

Rate this post!

☆

☆

☆

☆

☆