On an average, 350 new members are joining the group every week (a 7% growth.)

On an average, 13 discussions every week, but close to 300 comments each week is awesome. Shows that the group is very active. We also get a ton of promotions and jobs.

London, UK and San Francisco Bay Area seems to contributed highest number of members. Also pleasantly surprised to see Bangalore 5th on the list.

You can view all these detailed stats yourself at the group dashboard.

IMHO on a given team, in less than 6 months, an effective Scrum Master will make:

• themselves redundant
• process second-nature for the team

That would be the true test for their effectiveness.

In the mean time, I would look for:

• Apart from effectively facilitating (not enforcing) the Scrum ceremonies, is the SM helping the team understand the rationale behind those ceremonies?
• Is the SM creating a culture of safe-fail experimentation where the team can experiment, learn and grow beyond the standard Scrum ceremonies? If the team is not evolving their practices and work culture, is the SM really doing their job?
• Does the SM encourage System’s Thinking and uses techniques like Value Stream Maps, Five Whys, A3, etc. to identify & highlighting bottlenecks in the team?
• Has the SM been successful at creating Self-Organized Empowered Team? Or is the team waiting for directions from the SM?
• Is the SM able to emerge as a leaders and be the voice of the team, shielding the team from external interferences, yet creating a healthy collaborative culture?
• Is the SM able to motivate the team and steer them towards excellence?
• Is the SM recording and surfacing important and relevant data about the team’s performance to the team? Basically feeding the team, food for improvement.
• Is the SM proactive (instead of reactive) about resolving issues?
• Is the SM approachable? Believes in servant-leadership? Extremely knowledgeable about processes? Keen learner and open-minded?

It’s like I dont care about no process man…
Just hack some more code…ooohh
la da da da la da da la la da da

I was gonna groom the backlog until I got Age’il
I was gonna be at the standup but then I got Age’il
My project is still messed up and I know why (why man?)

‘Cause I got Age’il
Because I got Age’il
Because I got Age’il
La-da-da da da-da da

I was writing clean code before I got Age’il (C’mon y’all, check it out)
I could’a test-first or test-after but I got Age’il (uh uh la la da da)
I’m refactorin’ it next sprint and I know why (why man?) (hey hey)

‘Cause I got Age’il
Because I got Age’il
Because I got Age’il

I was gonna update my burn-down until I got Age’il (say what say what?)
I wasn’t gonna gamble with points but then I got Age’il (uh uh)
Now I’m completely burnt-out and I know why (why man)

‘Cause I got Age’il
Because I got Age’il
Because I got Age’il
La-da-da da da da

I was gonna do my code reviews but I was Age’il (uh, I’m serious man)
I was gonna refactor mercilessly but I was Age’il (uh)
Now I’m a Scrum Master (ha ha ha) and I know why (why man?)

‘Cause I got Age’il
Because I got Age’il
Because I got Age’il
La-da-da da da da

I was gonna go to retro before I got Age’il
I was gonna pay my tech-debt but then I got Age’il (no you wasn’t)
They scrapped my whole project and I know why (why man?)(yeah eh eh)

‘Cause I got Age’il
Because I got Age’il
Because I got Age’il
La-da-da da da da

I was gonna go to work but then I got Age’il (ohh, ohh)
I just got a new promotion but I got Age’il (la da da da da)
Now I’m selling Agile training and I know why (why man?)

‘Cause I got Age’il
Because I got Age’il
Because I got Age’il
La-da-da da da da

I messed up my entire life because I got Age’il (go go go)
I lost my kids and wife because I got Age’il (say what say what say what?)
Now I’m sleepin’ on the side walk and I know why (why man?)
(yeah yeah)

‘Cause I got Age’il
Because I got Age’il
Because I got Age’il
La-da-da da da da

la la da da da da la da da da shoobe do be do wa skibitty do da da da la
get jiggy with it scubbydooby wa ’cause I’m Age’il, ’cause I’m Age’il, ’cause I’m Age’il

• Visionary
• Can come up with a product vision which motivates, inspires and drives the team
• Aligns the product vision with company’s vision or mission
• Passionate Problem Solver
• Should have a knack of identifying real problems and ability to visualize a simple solution to those problems.
• Has good analytical & problem solving skills
• Subject Matter Expert
• Understands the domain well enough to envision a product to solve crux of the problem
• Able to answer questions regarding the domain for those creating the product
• End User Advocate
• Empathetic to end-users problems and needs
• Able to describe the product from an end-user’s perspective. Requires a deep understanding of users and use
• Is passionate about great user experience
• Customer Advocate
• Understands the needs of the business buying the product
• Ability to select a mix of features valuable to various different customers
• Business Advocate
• Can identify the business value and synthesize the business strategy as measurable product goals
• Has a good grasp of various business/revenue models and pricing strategies
• Capable of segmenting the market, sizing it and positioning a product (articulate the Unique Selling Proposition)
• Is good at competitive analysis and competitor profiling
• Able to create a product launch strategy
• Communicator
• Capable of communicating vision and intent – deferring detailed feature and design decisions to be made just in time
• Decision Maker
• Given a variety of conflicting goals and opinions, be the final decision maker for hard product decisions
• Designer
• Possess a deep understanding of (product) design thinking
• Able to work effectively with an evolving product design
• Planner
• Given the vision, should be able to work with the team to break it down into an iterative and incremental product plan
• Capable of creating a release roadmap with meaningful release goals
• Is feedback driven .i.e. very keen to inspect and adapt based on feedback
• Collaborator
• Able to work collaboratively with different roles to fulfill the product vision. Be inclusive and empathetic to the difficulties faced by the members of the cross-functional team
• Given all the different stakeholders should be able to balance their needs and priorities
• Empowers the team and encourages everyone to try new ideas and innovate

Disclaimer: This list is based on my personal experience but originally inspired by discussions with Jeff Patton.

In my experience its hard (not impossible) to find someone who possess all these skills. It requires years of hands-on experience.

Some companies form a Product Ownership team, comprising of different people, who can collectively bring these skills to the table. Personally I prefer supporting one person to gradually build these skills.

I amazed how easily companies get convinced that they can send their employees to a 2-day class on Product Ownership and acquire all these skills to be a certified Product Owner.

What do I mean by part-time coaching model?
A coach is onsite, working hands-on with the team for a week and then offsite (accessible via email & phone, but off the project) for a week. Basically, the coach is available on-off either alternative weeks or a some other timeframe.

Personally I’ve experience the following advantages of a part-time coaching model:

From the company & it’s employees’ point of view:

• When a I’m not there full time, teams realize they cannot fully depend on me. I’m not the bottleneck for making decisions. The teams start to take ownership and make more decisions on their own (usually by consulting me, but not waiting on me.)
• When I steps out for sometime and come back to the team, I bring a slightly fresh perspective and can pay attention to weak signals. Many times we get so engraved in what we are doing, that we might miss out paying attention to something else.
• Coaching can be intense. And have a little off-time, helps the teams get some breather. Which makes overall coaching more sustainable.
• As coaches we expect things to change much faster rate than usually they do. If we are there full-time, it might start bothering us. But with the on-off model, the slower rate of change seem more acceptable. Similarly the team does not feel pressurized to accept change at a rate that might not be sustainable or acceptable to them.
• The management seems to get more confidence in the whole engagement, because they can see things are not blowing up when the coach is not around.
• Last but not the least, it does have a good financial incentive for the company.

From the coach’s point of view:

• Having some downtime is good for the coach to build/upgrade their skills.
• Can help achieve a better work-life balance.
• From a risk management point of view, it allows a coach to take on multiple part-time client.

Hopefully, all of this leads to a more effective coaching engagement.

Its like having visiting card like this:

Instead of:

I had a few interesting take-aways from this discussion:

• A debt always has a notation that you need to pay it eventually (unless you default.) This is not true in case of a technical debt. There might be parts of your code which is a complete mess, but you don’t touch it and its fine to live with that debt. Or you might just decide to throw away that code since it served its purpose. You might never need to pay off that technical debt.
• Deep down in our psychology, the term “debt” trigger a negative thought. We strive hard to avoid a debt. However if you project the same thing as a lease, it seems to have a more positive feel. In the business world, taking on a lease, in many cases, can give you a good business advantage. In fact some might even consider it to be stupid not to lease out stuff.
• The important thing to consider is: what is the “Cost of Service” for a lease/debt? If the cost is significantly high, you are better off not taking it on. But if the cost is really low, it makes all economical sense to embrace it. We’ve learned that long-term, heavy interest leases/loans are a bad idea for that very reason. But a short-term, low interest loan can provide extra working capital to expand business.

IMHO it can really help teams to think of technical debt really in terms of the “cost of service” of a lease.

Beware not to make technical debt a dumping ground for tasks that the team wants to defer without a conscious, thoughtful reason. I’ve seen in many organizations, technical debt becomes an easy excuse for the team to skip things that are very important but for their short-sighted hasty decisions.

While the DoD thought-process is helpful, it can lead to certain unwanted behavior in your team. For example:

• DoD usually ends up being a measure of output, but rarely it focuses on outcome.
• In some teams, I’ve seen it disrupt true collaboration and instead encourage more of a contractual and “cover my @ss” mentality.
• DoD creates a false-sense/illusion of doneness. Unless you have real data showing users actually benefiting and using the feature/story, how can we say its done?
• I’ve also seen teams gold-plating stuff in the name of DoD. DoD encourages a all-or-nothing approach. Teams are forced to build fully sophisticated features/stories. We might not even be sure if those features/stories are really required or not.
• It get harder to practice iterative & incremental approach to develop features. DoD does not encourage experimenting with different sophistication levels of a feature.

I would much rather prefer the team members to truly collaborate on an-ongoing basis. Build features in an iterative and incremental fashion. Strongly focus on Simplicity (maximizing the amount of work NOT done.) IME Continuous Deployment is a great practice to drive some of this behavior.

The people who are freed of the additional skill (burden), slowly reduce practicing the skill and day-by-day they become weaker at that skill. Gradually, they are completely out of touch and stop caring about the skill. Ultimately, they start feeling that they are not qualified enough and also someone else with the specialized role is now really responsible for that skill.

The person with the specialized role, is exposed to more situation & starts practicing the skill a lot more. With all that practice, they hopefully get stronger at that skill. But in the process, as they are completely focused on this specialized skill, they care a less about other things.

Over a period of time, creating skill silos, who barely understand or appreciate the other side.

Net-net, IMHO specialized skills leads to local optima and might be good to start with, but not good for global optima over a period of time. The hard part with specialized roles is that once you are down this slippery slope, its very hard to back out.

Dysfunctional organizations with product, design, architecture, development, testing, deployment and production support silos reinforce my believe.

A really strong collaborative culture with collective ownership and frequent role rotation between these silos seems like the only way to rescue organizations out of this specialized role mess.

• C3: Coverage, Complexity & Churn – Instead of looking at each of these parameters in isolation, we generate C3 graph using a TreeMap and use the cumulative graph to see red spots in the product. Esp. helpful to quickly raise awareness.
  
• Slack: Every team members gets a 10-20% time every iteration to invest on things that hurt them.
• Scratch your Personal Itch day: Every iteration each team members gets 1 day to fix unplanned issues on the project
• Visitor from Hell: Every month have one person from other team visit you and give you feedback on various aspect of the team. Its up to the team to address these issues or not. But certainly can be used to pitch to the management for additional time to work on these issue.
• Code Walk Throughs: Every time a team member (or pair) implements something important, they give a code walk through or a demo to the rest of the team. This usually ensures team members don’t have crappy things when they give a demo.

• Manual Tests are more expensive and time consuming
• Manual Testing becomes mundane and boring
• Manual Tests are not reusable
• Manual Tests provide limited visibility and have to be repeated by all Stakeholders
• Automated Tests (Checks) can have varying scopes and may require less complex setup and teardown
• Automated Testing ensures repeatability (missing out)
• Automated Testing drives cleaner design
• Automated Tests provide a safety net for refactoring
• Automated Tests are living up-to-date specification document
• Automated Tests dose not clutter your code/console/logs

What criteria do you use for naming your product?

I’ve used the following:

1. AdWords: When people want to find something similar, what keywords are they searching for? I would use Google AdWords to find keywords/phrases that people are already searching for. Look for related searches.

2. Competitors: If there are similar products in the market, what have they named their product and what keywords are they focusing on?

3. Unique Name: Based on keywords from the first 2 steps and your own preference, pick a few unique name that communicates the outcome achieved by using your product.

For ex: if I was building a product which helps me search and find my files, I would call the product Found instead of File-Searcher or something else.

Sometimes, you might need to search for synonyms or replace certain characters in your name to make it distinctly unique.

Choose an appealing name. Something that appeals not only to you but also to your target audience. Choose a comforting or familiar name that conjures up pleasant memories so customers respond on an emotional level. Usually long or confusing names are not favourable.

Also try to avoid names that are spelled differently than they sound.

4. Domain Name: Is a .com domain available for this name? Also what about other popolar TLDs? Personally I prefer getting a .com, unless your product naturally blends with some other TLD. Like talk.to You want to make sure your domain name is different enough from your competitors’ domain name.

People generally make mistakes while typing URLs, you need to make sure there are no stupid websites with small variations of you domain name.

5. Trademark: Might be worth checking if your product name is already a registered trademark owned by someone else in the same business domain. Esp. in the country where you plan to sell your product. In the US you can search trademarks on USPTO’s website.

6. Test your name: Its generally a good idea to present your shortlisted names to a few people and see their reaction.

7. App Stores: Even though all popular App Stores allow duplicate app names, it might be worth checking if other apps use the same name. .i.e. if you plan to build an app as part of your product.

Wikipedia has an excellent article on this topic called: Product Naming

Even if the future is uncertain and we know it will change, we should always plan for the long-term. Without a plan, we cease to move forward.

I’m not necessarily in favor or against this philosophy. However I’m concerned about the following points:

• Effort: The effort required to put together an initial direction is very different from the effort required to put a (proper) plan together. Is that extra effort really worth it esp. when we know things will change?
• Attachment: Sometimes we get attached with our plans. Even when we see things are not quite inline with our plan, we think, its because we’ve not given enough time or we’ve not done justice to it.
• Conditioned: Sometimes I notice that when we have a plan in place, knowingly or unknowingly we stop watching out for certain things. Mentally we are at ease and we build a shield around us. We get in the groove of our plan and miss some wonderful opportunities along the way.

The amount of planning required seems to be directly proportional to the size of your team.

If your team consists of a couple of people, you can go fairly lightweight. And that’s my long-term plan to deal with uncertainty.