Certifications Boon or Bane? – You Decide

“Third party certification through reputable organizations can be an important tool for small businesses and the gives company the assurance that your suppliers are comprised of the ownership they claim.”

Certification is now a full-fledged industry, everyone is running around it like there is no tomorrow, The craze of the certifications is more seen in the IT sector as compared to the other sectors, specifically for Project Management, Agile, Six Sigma and not to forget at the organizational level for things like CMMI and ISO’s of the world

Senior management should now take 2 step backwards and perform a review of all the money that was spent on certifications, did we really get the ROI or the Cost Benefit analysis? Can we provide the measures that certifications have really helped the productivity of the individual or the group or the organization improve. Would the organization be able to show visible improvements in their TOP or BOTTOM line?

I have my own doubts of the data availability, a good part is that most of these certifications like PMP, Agile , CMMI and so on …. Advocate the usage of metrics and measurement to understand how things are moving in the system, but we rarely use these measurements to prove that the money that we have spent has been really put to good use.

Industry and organizations are going crazy over certifications and spend a huge amount of dollars in acquiring a certificate, to be there on the Wall. I recollect an interesting conversation with a Quality Head for one of the esteemed organization, who had just delivered a CMMI Level 5 successful appraisal for the organization, He was mentioning that his job is over here and with the experience of this journey he plans to move on to a different organization at a better position and obviously a better packet to carry home, On response to my curiosity based questions, he responded that the he has nothing more to add to the current organization. This made me think, that did the organization hire him to get a certificate on the wall types, Is getting certificate the only requirement of the organization, where there improvements in the system, did the ROI of the organization improve? Did the defect count go down, or did they have better schedule performance.

We, in the industry have failed to understand the value and reasons for certification, It has become more of a decoration element on the wall and to gain a few bragging brownies

Project management certifications are booming. However, it seems to me that the main beneficiaries of the certification gold rush are the certifiers, not the certified. There are a lot of articles aimed convincing people of the value of certifications. Here I take a different, and possibly contrary approach: I’ll give you two common, but (in my opinion) wrong, reasons for pursuing PM certification.

My motivation for writing this post is a recent conversation I had with a participant of my PMP batch. It went like this:

“Do you think a PM certification is worth the effort?”

“Depends on what you want out of it,” I replied.

“Well I reckon it will make me a better project manager and help me stand out from the crowd .”

Now I don’t remember what I said in reply, but he’s wrong on both counts. Here’s why:

1. To become a competent project manager: A cert does not a PM make. Preparing for a certification will teach you formal project management processes as decreed by a particular certifying authority. These processes are easy to learn by reading a book or two. The “hard bits” of project management – negotiation, people skills, crisis management, conflict resolution, prioritization, stakeholder management (I could go on and on but I’m sure you get my point) – are not, and cannot be, learnt through certification.

2. To stand out from the crowd: The fallacy here is easy to see: certifying authorities push their credentials like there’s no tomorrow, hence the number of people gaining certs is growing rapidly. That being so, the “stand out from the crowd” factor is getting smaller and smaller every day.

Before I conclude, I should come clean and admit that I have a cert or two. My main reason for getting certified was (is!) that it is a good way to learn about commonly used project management processes and the associated terminology. The certs don’t make me a better project manager, and they won’t help me get that dream job either. However, they do help me recognize jargon-laden bull dust when I hear it (which, unfortunately, is quite often).

In the end, formal knowledge is always useful. So, gaining a cert won’t hurt, but be sure you aren’t doing it for the wrong reasons.

Agile, But not Agile

I am sure that is post of mine would resonate with the readers with respect to that we are Agile, but Not Agile. The best part of the story is that most of the organization in India are doing something or the other in the world of Agile and trying to make their hands dirty with the concept and implementation of Agile.

Not sure if the organizations that have adopted Agile, have done any retrospective on their adoption of Agile, we expect that at the end of the iteration / sprint cycle, the team would perform the retrospective and learn from their practices that needs to be improved. Not sure why the same yard stick is not applied at the organizational level. The management expects all the principles and practices to be applied at the team level, but when it comes to its own application, they have washed their hands off

I am finding it very difficult in India for Agile to be practiced in true spirits, not saying that all organizations can be clubbed together, nor am I trying to paint the town red, but the real story is that in most of the places, I have not observed majority of the Agile Manifesto and Principles adopted and done in the true manner

Most of the people and the Agilist that I have met have given the impression of working with Agile and related stuff with the waterfall mindset. Not sure if the required change would come via this element / approach.

Speaking on the same, Lets discuss one of the principles of Agile …. “Customer and the Development Team should speak daily”, All of the agile methods require that the Customer (in this case the Product Owner) would be based at the same location as that of the team, but this is hardly practiced in real life execution of projects, due to the Onsite / Offshore engagement models, where the product owner is not located in the same location as that of the development team. Have observed practices such as proxy product owner, it is like complicating the matters beyond repairs, If the Proxy PO can do the job, then why have the PO? During my training and consulting with various customers, Have always heard that if we have any query to resolve with respect to the user stories, it is difficult, as we have nobody to bank upon, the queries are delayed, at times information is provided at the eleventh hour. This has its own impact on the quality of the deliverable that we make to the customer.

One of the other major issues faced by team adopting Agile and related elements in India is the changes that come in the sprint after the commitment has been done during sprint planning meeting. It is stated and given that no changes in duration or goals of the sprint, but this is not in place for majority of the organization. Every change has a cost, but agile does not account for this. The result? People often change really big things late in the game using the rationale that since it’s an agile project, it can handle it. This encourages poor and irresponsible planning while hiding its effects. As iterations / sprint continue and the defect list grows, the customer becomes more frustrated—not only because of the lack of quality, but because delivery expectations aren’t being met either. The only way the project can handle this is by adding iterations / sprints. As that happens, defects that might have been easy to fix at one point get harder and harder to fix, since the code base keeps changing.

Remember, the goal is to deliver a quality product on time and to budget; as a rule, there are always some elements that have to be sacrificed to fulfil the needs of the others. It’s the How to Develop Next-Generation Scrum Masters / Agile Project Managers role of the project manager to define and maintain the project priorities so they can function as a decision framework for team members as they carry out their tasks.

Off-late I am in touch with a number of customer, who want to actually redefine the concept of Agile to suit their requirements and needs of working, well I see nothing wrong in this approach, but my recommendation is not qualify that we are following Agile, it is a misnomer, We are giving false impression and views to the world of our capabilities and understanding of Agile

People love certifications in the industry where I work. But when a particular methodology gets popular enough that a certification industry rises around it, organizations try to adopt that methodology without bothering to understand it. It’s as if certification replaces the need for thinking or experimenting. It becomes a check in a box: “We’re certified, therefore we know what we’re doing and you should hire us.” The primary focus becomes figuring out what you need to go to get certified; figuring out ways to actually improve productivity becomes secondary. That’s the problem I have with certification – I’ve seen it happen multiple times (and even been involved in it), but it’s particularly ironic with Agile development.

There’s a reason behind the demand for certification – it’s human nature to want a simple way of discriminating those who know what they’re doing from those who don’t (especially if you don’t either) – so I’m not sure there’s a good solution. In any case, I don’t have a problem with scrum training, just certification.

It high time, that we re-channelize our focus and energy to do the real thing rather than running after pseudo stuff ….. My prediction, Agile has lived its utility (though more than 70% of the IT industry does not implement and practice the way it should be done), We are now waiting for the next BIG wave to come in and that in my view would be DEVOPS

Creating, Sustaining and Scaling – Agile Development Team

The squad (aka Development team in Agile) – nine folks. The number of guys that could fit in a tent,” It has been identified that the way to build a scalable organization is to focus on the basic building blocks – small, stable, multidisciplinary teams that are expected to independently tackle problems, make decisions, and get things done.

“When it comes to building a deeply efficient engineering organization, there are several things you can do to move the needle:
• Build strong teams first. Assign them problems later.
• Keep teams together.
• Go modular. Remove dependencies.
• Establish a short, regular ship cycle.”

Concept is to have a decent team size that is the two-pizza team – a team small enough to be fed with two pizzas. A team includes everyone needed to design, deliver, and support the service – from specifications to operations. If a service is too large for a two-pizza team, Organization should split the service into smaller pieces rather than to combine teams to deal with the larger service, because this preserves the dynamic interactions of small teams.

WHAT COULD GO WRONG?

If it works for larger organizations like Salesforce, Amazon and Twitter, surely it will work for you… So you form a lot of small, independent, multidisciplinary teams and you are careful to give them all clear goals. What could go wrong with that?

THE DILEMMA

It is a beautiful thing when the building block squads of an organization gel into high performance teams and can be counted on to meet challenging goals. But tricky part is, once you create these strong independent teams, how do you get them to work together? How do teams maintain their autonomous character while working in concert with an increasingly large network of other teams? How do you make sure that each team has a clear goal, but none of the goals are in conflict?

In an agile environment, the Scrum Master’s role is to set up strong teams, to be sure, but it is also to devise a system – let’s call it a goal system –which assigns goals to teams. This is no easy task. Teams need clear, meaningful goals; they have to be the right goals; teams must have the capacity, capability and autonomy to achieve their goals; and most important, the goals cannot conflict with each other.

One of the things Scrum has contributed to the practice of software development is the idea that small autonomous teams perform much better than large project teams or single-discipline teams that work in sequence. So Scrum provides the building blocks of scale, but unfortunately, it does not contain a scalable system for choosing team goals, making sure they contribute to organizational goals and are in sync with the goals of other teams. So we need to look elsewhere for ways to set up a goal system.

THE THEORY OF CONSTRAINTS

When the Constraint is Technical

The first step – after clarifying the overall system purpose and goal – is to find the biggest constraint to achieving that goal. For purpose of discussion, let’s choose one of the most typical technical constraints encountered in delivering a software system: the integration of various components of the system without the introduction of defects or unintended consequences. In fact, project organizations typically allocate a third or more of the project time to release overhead – including integration, testing, fixing defects, and deployment – with the largest portion going to finding and fixing problems discovered during integration. When integration is the system constraint, TOC tells us that the most important focus for development teams should be removing this constraint.

Agile approaches to software development recommend the frequent delivery of working software to customers. When this recommendation is followed literally (software is released to end customers frequently), the integration constraint is regularly exposed and has to be confronted. One of the earliest agile approaches, Extreme Programming (XP), includes technical practices such as Test Driven Development and Continuous Integration that help make frequent releases practical. Continuous Delivery, which expands on these practices, has gained widespread favour as the agile approach which explicitly focuses on the integration constraint. In Continuous Delivery we find actionable advice on how to tackle the integration problem with techniques that scale across large networks of teams.

If everyone working on a system is trying to stabilize and improve the rate at which tested, integrated software is successfully released to end customers, then teams across the system will naturally have to work together and will find that their goals are compatible.
When the Constraint is Knowledge

More often than not, however, technical issues are not the biggest constraint in system development and the fundamental problem is not an integration problem, it is a design problem or a fitness-for-use problem. Far too often we end up with a system that doesn’t work well or is difficult to use. In this case, the biggest constraint in developing software systems is the way in which we decide what to build and parse that decision amongst the teams doing the work.

Organizations with an agile / lean mind-set would frame the problem differently. They are likely to identify the biggest barrier to making good decisions as incomplete knowledge, and thus the biggest constraint of the system would be the rate at which knowledge is generated. So a lean organization would focus on the feedback loop between customers and development teams. They would decrease the length of the feedback loop, increase the speed of the feedback loop, and remove barriers to the free flow of information inside the feedback loop. These organizations would say: If we can test our assumptions and designs more quickly we will learn faster and make better decisions.

Good Leaders set examples

Good and great leaders set examples on the following parameters: Help your team practice these elements to be able to scale and add value to themselves, product, organization and the customers:

Clarity – Eighty percent of success comes from being clear on who you are, what you believe in and what you want.

Competence – You can’t climb to the next rung on the ladder until you are excellent at what you do now.

Constraints – Eighty percent of all obstacles to success come from within. Find out what is constraining in you or your company and deal with it

Concentration – The ability to focus on one thing single-mindedly and see it through until it’s done takes more character than anything else.

Creativity – Flood your life with ideas from many sources. Creativity needs to be exercised like a muscle, if you don’t use it you’ll lose it.

Courage – Most in demand and least in supply, courage is the willingness to do the things you know are right

Continuous learning – Read, at the very least, one book a week on industry / sector / domain / business to keep you miles ahead of the competition. And just as you eat and bathe, organize your time so you spend 30 minutes a day exploring e-mail, sending messages, going through web sites, because like exercise, it’s the only way you can keep on top of technology. If you get away from it, you’ll lose your edge.

Triple Scrum Master – a Three in One Role

The old-fashioned scrum master would be limited to a thought process of getting the team more productivity, improve impediments, coaching the stakeholders on the value system of Scrum and so on … 

With the changing environment, the new demands of the customers and also the market, with the technology changing rapidly, the approach of Scrum Master should also change and adopt new ideas and be an evangelist thought leader and an idea generating machine. Having said all this does not mean nor am I endorsing the idea the role is to be done away or the earlier responsibilities are no longer needed, what I am proposing is taking the role to the next level of operations.

The new concept of 3 in 1 should be as follows:

Expect the Scrum Master to act and behave like a CEO for his / her projects, at times, the role would demand the nature of a CFO to be seen and finally the original job of a Scrum Master

I am sure all of us would be wondering what is this concept of CEO and CFO in the business of Scrum. As we say “Management has no role in Scrum, but Scrum Master is a management role”

I would and always like to consider a Project like a mini organization, which means that there would be a need to have CEO and CFO to manage the operations and costing of the project. With this understanding, I propose the triple role of CEO, CFO Cum Scrum Master for all our existing Scrum Masters.

It is a unique thought and may be a little ahead of its time in the market right now, but it is always important to be a trend setter rather than a follower of a best practice

Scrum Master in the shoes of the CEO

One needs to think at high strategic level for which the thinking process needs to change from the current behaviour patterns, The following would be the elements to practice and demonstrate:

As a CEO Scrum Master should:

The Multiplier Effect

  • Display the ability to energize people, Build a team of high energy professionals who would always play to win the game (read … Successful deliveries of sprint, adding business value to the customer)by choac
  • Translate complex business strategies into motivating goals and objectives
  • Make the team self-sustainable coaching the team and mentoring the individuals at regular intervals

Assume Responsibility

  • Display the ability to mobilise the organization, Work vertically and horizontally and diagonally with different stakeholders and establish credibility and respect from others
  • Understand the situation, take responsibility and respond quickly and effectively
  • Have a strong sense of ownership / passion and see things through till the very end
  • Have the ability to turn diversity into synergy, Synthesize the positive elements of each culture, gender and nationality, Be effective in cross culture and a multi-functional environment
  • Adapt to own style and approach as needed and required

Translate ideas into reality

  • Innovate, Execute and be decisive
  • Get ready to spark a change
  • Demonstrate ingenuity and creativity – think through ideas, build on them, display advocacy and gain buy-in
  • Develop innovative strategies that help build the team competitive edge and / or create the desired change and transformation
  • Encourage ‘Calculated risk’ – Foster a culture where people generate and implement new ideas

Display People centricity , empathy and listening

  • Listen deeply and objectively to what is said / unsaid and with an open mind , empathise and build trust
  • Proactively engage and collaborate with customers and partners to add value and create a winning partnership
  • Build a culture of constructive feedback. See out and act on both internal and external feedback. Give critical feedback in a polite manner

As a CFO Scrum Master should:

Think and Act with focus on profit

  • Manage elements for short and long terms
  • Identify and capitalize on opportunities to optimise resources, reduce cost, reduce waste and create sustainable value
  • Think like and investor
  • Drive higher financial results by improve the team performance, improving the quality of deliverables, maximizing the revenues (improvement in velocity)

As a Scrum Master, Scrum Master should:

  • Perform and conduct the role of the Scrum Master to the highest level as needed and demanded by the situation

By performing 3 different roles, the idea, is to expand the thought process and thinking approaches. The concept is not to wait for the results to come, but to create an approach, where results would be as per requirements.

Just like what we have a retrospective for the team at the end of each sprint, there needs to be a concept of Self-Retrospective performed by the Scrum Master of what he or she could have done differently and have the results behave in the manner and fashion as required.

There should be a regular forum in the organization for the Scrum Masters, where in they can come and discuss the issues and challenges in the system and seek ideas and opinion of other Scrum Master to see what can be applied from the learnings of others. It is great and a noble idea to learn from your own mistakes, but in the competitive world today to move forward , one needs to learn from the mistakes of others and ensure that we do not repeat them.

Let’s change the Phrase “History repeats itself”. It high time now !!!

Launching Agile Scrum – How to prevent a Flat tire?

Scrum is an approach that endeavours to create a profitable business by relentlessly focusing on what is of value to the customer. It is a philosophy that not only makes your business profitable but also provides you with an engine for continual improvement

Let’s start with an excellent quote from Mike Cohn (www.mountaingoatsoftware)

“Scrum is an agile framework that allows us to focus on delivering the highest business value in the shortest time.” (Cohn 2007a). Selling anything to anybody requires the element of “What for me in this one?”, If are able to provide justified, understandable and convincing answers to the business, management and the development team involved, the process and approach would be more streamlined.

At a tactical level, the implementation of Scrum in an organization would result in the following:

  • Reduction in cycle time
  • Reduction in waiting time
  • Reduction in query time
  • Reduction in throughput time
  • Reduction in defects
  • Ability to execute flawless process

The first step, even before you make a holistic roadmap, is to create interest in your Senior management so that they start to appreciate what Scrum is all about and understand the underlying principles

A few things that one should do in order to get traction in the organization for Scrum are:

  • Get an Agile Scrum thought leader to address the Sr. Mgmt. of the organization
  • Let representatives from companies who have implemented Scrum come and make a presentation in your company highlighting the success stories
  • Arrange visits of your senior management to companies, that have successfully implemented Scrum, try and get these in similar product lines of business lines (you would be able to find instant connect with the management)

Introduction of Agile Scrum should impact all the key business objectives of the organization; Looking at Agile Scrum in isolation would not bring the desired changes in the system

Driving process ownership would require that the top management be willing to change the way the organization is structured

On an Agile Scrum projects, roles have well defined meaning and boundaries in the system. All individuals are aligned to one of the defined roles in the system (in an idealistic world) so that ownerships can be defined for all deliverables and managing the required output and issues pertaining to them

Lack of role ownership results in a number of inefficiencies and impacts the overall effectiveness of the project / output.

Lack of role ownership is a major cause of process discomforts and issues related to the process being able to meet the desired outcomes. Driving role ownership would require that the Sr. management be willing to change the company is structured and operated (move away from legacy approach to the new Agile Scrum method of working)

Scrum can get qualified with a new name as  Time management approach. This is because one of the prime objectives is to reduce the lead time for delivery, making quick turnarounds with great quality for the customer, which would bring immediate value to the system.

A healthy implementation of Agile Scrum practices should have a positive impact on each of the 4 parameters of business namely:

  1. Flexibility
  2. Employee Engagement
  3. Cost / Revenue
  4. Customer Engagement

The management should regularly monitor the performance of each of these 4 metrics. Would recommend that the Leadership team should be spending about 30 mins every month (or least 15 mins post each sprint) to ascertain whether their journey is underway as desired.

Implementing Scrum is about driving a fundamental change in the way Organization and projects operate. As with all change initiatives it is imperative that we communicate to all concerned the reasons and benefits of implementing Scrum. It is important to remember that awareness without immediate action is of no use. If there is a long gap between communication and action, team can lose sight of what the goal is. It is recommended that the action on Scrum should commence within 2 weeks of the alignment session.

Setup a Scrum office (in similar manner like a PMO function). This office would have Certified Scrum Coach as a lead in the system, the profile of this function / office should to manage adoption, deployment and sustain the gains from the transformation. The team is entrusted with this job is called the Scrum Office. The Scrum coach takes the leadership position

Scrum Master should be acting as a CIO (Chief Improvement Officer) for the project and also for the Organization. Create a culture of continuous improvement , value thinking and constant reflection. All decisions and changes should be done with team’s involvement

Change takes time, It is not like instant noodles. Adopting and implementing Scrum in any organization would require a significant shift in organizational mind-set that include breaking up of the old habits and this process would take time. There would be a lead time required for the new set of approaches to be sinked in the minds of all relevant stakeholders including the development team members, as they would be used to the command-and-control style of working, before they embrace the Self-Organizing, Self-management concept and start to practice the same in the idealistic manner.

One of things that I would strongly recommend that Scrum Master to do is to have performed the art of observation.

Mastering the art of observation is a key aspect in Agile Scrum adoption and implementation. This is not easy and the Organization and the Scrum Master needs to really invest time to master the same. Observation refers to what you see in a workplace or a certain context as you walk through it or are a part of it. This can be done via a leadership mandate; It has to be taught how do it.

The following are a few objectives which can be accomplished through observation:

  • See at source what is happening?
  • Discover potential problems
  • Get beyond data and see the facts
  • Understand the customer
  • Understanding what is working and not working in the team

At times it is important to perform a GEMBA (concept from Lean to see the work at source) and observation information at source. Sometimes observations would lead you to unlearn a few things, that one would have thought working as a standard approach. Of course observation has to be followed by evaluation, analysis and inferences.

Scrum Master with its ability and role in the project should facilitate the discussion with the development team members to define and implement process that would be working for the team. Scrum Master should ensure that the team understands and appreciates the following:

  • Process should have effectiveness criteria built in
  • Process should have efficiency criteria built in

My worry is that in today’s fast working world and changing technology, there is little element of patience with the top management of the organization, somewhere in this rat race, we have actually forgotten the elements of people , feelings, respect and empathy along with listening.

Patience and nurturing is the name of the game and a supportive organization will no doubt reap the benefits of this investment in long run.  Should the organization and the Scrum Master not practice the patience part of the game, very soon we shall be Patient ourselves

Scrum Master – A non-playing captain of the team

In the 3rd and last part of this series, describing a new dimension focusing on the various roles in the Scrum team, we shall focus on Scrum Master.

Many a books have been written and workshops have been conducted on the role of Scrum Master in any Scrum team / project. A lot of focus has been provided in the CSM workshops and other certifications as available in the market on the role of SM. The most interesting part of the SM profile is that one is not managing the development team, but is still accountable for the outcome of the system. It is like a coach sitting outside the boundary line and watching the team play the match, interestingly cannot participate in the activities of the team, cannot guide them during the match and have to wait for an appropriate time to have discussions with the team.

There are at least two major influences that affect how individuals perform in their environment. These influences include:

  • The type of leadership that exists,
  • Personal motivation.

For a Scrum Master to be successful, it would require the influencing ability that would include the following (but not restricted to):

  • Communication Skills
  • Interpersonal Skills
  • Team effectiveness
  • Leading and Motivation

Equally important are elements such as:

  • Responsible
  • Humble
  • Collaborative
  • Committed
  • Influential
  • Knowledgeable

But we would focus on the influencing ability and they would include for us the following:

Communication Skills

Having effective communication skills is imperative for the success in the role of SM. Positive communication will certainly increase the opportunities for the SM to effectively deal with the stakeholders in and out of the project. Having good communication skills will enable SM to get ahead in certain areas where others who are less assertive may not succeed.

Couple of important elements to keep in mind while practicing the fine art of communication are:

  1. Body Language

Do not shy away from the team member or other stakeholders with whom you are speaking. Be sure to maintain a relaxed, but not slouching posture, regardless whether you are the one speaking or listening. Other things that ensure your body is communicating your attentiveness to the conversation can include:

  1. Making eye contact.
  2. Nodding occasionally to acknowledge a strong point in the conversation.
  3. Standing with hands clasped in front of you, never crossing your arms.
  4. Not displaying nervous ticks such as wringing hands, picking at your nails, or anything that the person communicating with you will view as a distraction from their conversation.

Patience

  • During your communications with others always give them time to communicate their issues as well. Remaining focused on what they are trying to communicate will show them that you are indeed open to assisting with their issues.
  • Many of people’s communication lines tend to break down on the side where impatience is in a rush to get out of the conversation. Since you cannot control the other side, do yourself a favor and take a breath.
  • The conversation you’re involved in is important. This is one area where the current project managers’ converted Scrum Masters have failed, as they have lived the life of command and control which is diagonally opposite to the role and profile of the SM.
  • If you are confused as to what someone may be requesting, than repeat back to him or her what you think they said and ask if that is correct. Often this will inspire the speaker to be more in-depth about their needs, which will help you to understand them fully.
  • The main task for the SM should be to understand the team and the stakeholder’s needs and requirements. This ability will stand in good for him

 Interpersonal Skills

One of the most important pillars for the Scrum Master to demonstrate is good quality of interpersonal skills.

Interpersonal skills include the habit, attitude, manners, appearance and behaviour we use around other people, which affect how we get along with other people

 Interpersonal skills would involve:

  • Effectively translating and conveying information.
  • Being able to accurately interpret other people’s emotions.
  • Being sensitive to other people’s feelings.
  • Calmly arriving at resolutions to conflict.
  • Avoiding gossip.
  • Being polite.

 To have good interpersonal skills, Scrum Master should:

Practice empathy. Putting oneself in the position of another person allows one to see things from a different perspective. When people feel understood, they tend to be less combative, leading to greater understanding and unity.

  • Be inclusive. At work, practice helping people to feel included. Avoid behaviours that exclude others or make them feel like outsiders.
  • Be trustworthy. Relationships are more stable when 2 people trust each another. Keep commitments and confidences to increase trust
  • Examine personal ethics. People tend to trust those who are self-aware and who do not abuse their power. Practice integrity in one’s relationships by examining the impact of behaviours and decisions on others

 Leading and Motivation

 Scrum Master plays a critical role in leading and motivating the development team to excel the heights of great performance and good working software deliverables

Development team may be motivated by factors in the external environment such as pay, supervision, benefits, and job perks. This is referred to as extrinsic motivation. They may also be motivated by the relationship between the members and the kind of work that they do. This type of motivation is called intrinsic motivation. These factors often exist simultaneously, but we will distinguish between them as they relate to specific levels of motivation.

We shall explore the motivational elements of a different nature and see how a Scrum Master can adopt and have these implemented in his / her work culture to ensure that the team that he is working with is motivated to deliver excellent software and solutions to the customer / PO

Need for achievement: Team members in this category have a strong desire to perform challenging tasks well. They have a preference for situations where personal responsibility can be taken for successful outcomes. The goals they set provide for moderate and calculated risk, and the team members seeks performance feedback to allow for modification and to ensure success.

Need for affiliation: Team members in this category display a need to establish and maintain friendly, compatible relationships. They have a need to like other people and want others to like them. They have an ability to create social networks that will result in meeting these needs.

Need for power: Team members in this category have a strong need to have influence over others. They wish to make a significant impact and impression on those with whom they come in contact.

Different team members would get motivated by different elements. The task of Scrum Master is to identify the individual team member and areas of their interest and motivation level, Not all of the above would be required to motivate every individual. Each person is different and so also their needs are different.

Now speaking about leading …

In many circles, there is continuous debate about whether leaders are born or developed. If we reflect on our discussion about motivation, we will see that humans are very complicated and are made up of a number of traits. As with motivation, these influences are both inherited and acquired from our environment and influences. We will continue this discussion on the assumption that leadership can be developed

Leadership may be defined as: the influence that particular individuals (leaders) exert upon the goal achievement of others (subordinates) in an organizational context.

There are other issues that must also be acknowledged. There are two types of leaders: emergent leaders – those who earn leadership positions through their expertise, skills, abilities to influence others, or personal acceptability by the group; and assigned leaders – those who are given power to exercise influence through appointment. Scrum Master should be the emergent leader, who earns his / her stripes in the system. Just because one is a Scrum Master, the position does not provide automatic control over the team. For that matter the Scrum Master does not control the team.

Emergent leaders (Scrum Masters) hold their position as a consequence of their appeal to their development team. Their role is safe only as long as the group is attracted to these attributes and conditions. Should these positions change, or the group finds other influences, a lack of support or outside forces may undermine the Scrum Master’s role. The role, therefore, is dependent on performance and any real or perceived faltering will quickly translate into lack of support and that would produce a non-productive Scrum Master

The most important activities of Scrum Master is to clarify the path to various goals of interest to team members, thus effective Scrum Masters form a connection between team goals and organizational goals. Since the role of Scrum Master is about increasing team performance through motivation.

Environmental factors that impact on leadership include the following:

  1. The appropriateness of the Scrum Master’s style to the situation will have a major impact on the behaviour of the team.
  2. Task clarity, urgency and subordinate empathy will affect performance and motivation.
  3. Scrum Master’s qualifications and knowledge will build team confidence and loyalty.
  4. There is probably no substitute for being in the right place at the right time.

As a closing thought to this current series of different thought process on various roles in Scrum, I would say, that we need to think different ways of adopting the methods of executing the Scrum projects, Scrum and related guidelines were produced / documented about 2 decades ago, things have moved since then, methods of doing things have changed, therefore there needs to be a new thought process in place to adapt to the changing environment.

As we say in Agile “Inspect and Adapt”

 

Good enough is the enemy of great — Development team need to have an execution focus

In the 2nd part of this series, describing a new dimension focusing on the various roles in the Scrum team, In this offering, we shall focus on Development team.

Very recently in a discussion with one of my customers, I heard a very interesting statement and that was “Good enough is the enemy of great”. This statement started ringing bells and whistles in my thought process to analyse the statement and understand the hard and true meaning of the same. Many a times, I am sure most of us would have made that statement of “Good enough”, without realizing that good enough, does not mean perfect or great, we have missed out on something and settled for something less.

This same concept applies to the development teams. Many a times with the development team, we typically tend to focus on the technical side of the discussion, this would not do justice to the role that the development team has to play and perform in a scrum environment.

Slide1

For any development team, other than the technical acumen they also need to have a good execution focus. Great technical team, rely on execution of ideas and implement them, in order to derive great benefits from the system

For a development team to be successful, it would require the execution focus on the following:

Result orientation

  • Customer Focus
  • Compliance and Process Management
  • Planning and Organization
  • Decision Taking

The above elements may not follow any specific order, but all of them would be required for a development team to move from good to great

 

Result Orientation

Result orientation is a term used to describe “Knowing what results are important, and focusing on the resources to achieve them”

This means that the development team should be more interested in the final outcome rather than going through a process. In many ways it is a good thing, as long as the desired result is a honourable thing and that the process has integrity. One could say it doesn’t matter how you get there as long as you get there, but not good if it has a detrimental effect on other areas such moral of the team, ethical issues in the team and so on.

Result oriented refers to a form of team strategy, which is focused on achievements and outcomes. The strategy aims at balancing and satisfying the needs of all relevant stakeholders. The focus of individuals in the development team is to make things happen.

Result orientation would involve the following elements, for the sake of simplicity, we shall look at them as level of approaches that an individual can achieve in a team to bring higher degree of results along with transparencies and team in whole

The levels of approaches are as follows:

Level 1

Stays focused on results

  • Promptly and efficiently completes work assignments based on self –allocation approach
  • Aligns personal work with team/unit goals.
  • Plans, prioritizes and balances work to meet commitments, goals and deadlines.
  • Stays focused on goals despite obstacles and disruptions.
  • Compares work performance and outcomes against standards to achieve quality results.

Level 2

Seeks to improve personal performance

  • Sets challenging yet realistic personal goals in line with team/unit goals.
  • Looks for ways to improve personal efficiency.
  • Anticipates, identifies and effectively deals with problems or risks.
  • Plans for contingencies to deal with unexpected events.
  • Develops personal work plans to structure work and achieve required results.
  • Evaluates own work performance and identifies ways to improve it.

Level 3

Seeks to improve team performance

  • Uses appropriate tools, methods and criteria to regularly evaluate work processes, services or deliverables.
  • Challenges ineffective work processes and offers constructive alternatives.
  • Establishes effective team methods for assigning, managing and tracking work.
  • Develops systems to organize, track and share information.
  • Solicits and/or provides information that could affect the planning, programs and decision-making for the team.
  • Sets the expected standards and criteria for measuring success.

Customer Focus

A traditional statement in any business is that “Your customer had a requirement yesterday, they would tell you today and we shall deliver it tomorrow”, this statement shows that we are already behind by 3 days in regards of full filling the needs of the customer.

Successful customer-focused strategy puts the customer firmly in the centre of every scrum team decision. Customers like to feel special and appreciated, so responding to customers in a way that makes them feel important and valued is one way to encourage customer involvement. Formal / Informal methods can be adopted for eliciting some customer feedback, which is an important link in the customer retention chain.

Customers are looking to have their needs addressed quickly with a hassle free approach. Customers expect a quick response time.

Customer feedback, both positive and negative, is invaluable to a team, yet a surprising number of scrum teams fail to obtain this. Negative feedback does not have to be a bad thing, particularly if the customer’s view is dealt with quickly.  Put yourself in your PO’s shoes; what is their first experience with your product? Do they like it, Is there Love at first sight?

Practices of customer focus involve the establishment of links between customer needs and satisfaction and internal processes

Customers are the most important stakeholders for scrum team.

For any Scrum team to ring in Customer Focus in their approach, the following elements would be important:

A)       Customer Knowledge

Development team should know the needs of their customers’ and what they think about the capabilities of the team. Team may be able to develop mutually beneficial knowledge sharing relationships with customers by talking to them about their future requirements, their ideas, their thought process and discussing how you might be able to develop your own products or services to ensure that you meet their needs.

This might just go against the idea of Scrum where we live by the sprint and really not worry about the larger picture, but for any successful team, one would require to have 2 views of any system / product and they would be:

  • The Big Picture view
  • The Tunnel vision

The important element is to know, which one to apply when, Tunnel vision is important to focus on the current sprint and Big picture view is required for the large understanding of the product in general

Teams should be careful not to lose the skills or experience your project has built up. You would need to find formal ways of sharing your teams’ knowledge about the best ways of doing things. For example, you might create procedural guidance based on your teams’ best practice. Create a knowledge strategy for your development team

B)       Customer Requirements

This is best done by the Product owner, but the development team has equal responsibility of understanding the requirements, seeking clarifications on the needs of the feature / user story (for can we say requirement).

Every time, the development team has a look at the user story, the following elements should be in discussion:

  • Do we have adequate clarity on the requirement / user story?
  • Are the requirements / user stories conflicting?
  • Are the requirements / user stories ambiguous?
  • Are the requirements / user stories testable?
  • Analyse operational concepts and scenarios to refine the customer needs, constraints, and interfaces and to discover new requirements.

The idea of the above analysis is not to identify the “Do-ability” of the user story, but more on the lines of the goodness of the user story

C)       Customer Involvement

Even the most ingenious invention will be a market failure if it does not meet the needs of the customers

For a development team in Scrum, the first and the direct customer would be the Product Owner.

Customer involvement refers to ways which in turn become part of the process and the extent of their participation. This is particularly important if your team involves a high level of customer contact, which is again a basic need of scrum, based on its manifesto and principles

More customer involvement can mean better quality, faster delivery, greater flexibility, and even lower cost. The advantages of a more customer-focused process might increase the net value to your customer. Some customers seek active participation in and control over the process, particularly if they will enjoy savings in both price and time and this is the space, that the development team should guard itself against and ensure that involvement of the customer is at the right level, which does not disturb the process and also provides valuable insights into the system

By allowing customers / end-users to become idea generators and co-creators of new products or improvements to already-existing systems, it becomes possible to move beyond the customers’ expressed needs to a comprehension of their latent or unarticulated needs.

In the near future, organizations and development teams would need to be able to create processes facilitating collaboration during the innovation thought process. The time has come for a true Customer Collaboration.

D)       Customer Feedback

For a development team, getting customer feedback is of prime importance, otherwise one would not know, if we are moving in the right direction, what changes to the approach are required and so on …

The traditional approach of Scrum was always to use the sprint review ceremony to solicitate the feedback on the work performed during the sprint, but with the growing needs of the customer, dynamic environment of doing business, the scrum concept itself now needs to scale to provide much quicker feedback so that by the end of the Sprint cycle, the customer really has something that could qualify for “Potentially Shippable Software Increment”

The essence of the customer feedback can be summarized as; when customers feel that a development team truly cares about them and what they think. When a team makes changes according to feedback, it shows that they truly listen and respect those opinions, it is important to remember that we shall welcome the change to harness the competitive advantage for our customers.

Compliance and Process Management

Process transparency is the heart of compliance and quality management. It is about how a team operates – who does what, why and when – is unclear; the Scrum team will be unable to effectively institute business controls, policies, procedures, and a system to sustain operational excellence.

In the growing space of CMMI and ISO frameworks, this subject of compliance and process management has gained more prominence than before. In the traditional projects, we would have a regular frequency defined auditing process that gives us real insights into violation of business process rules. The challenges posed by the need to implement compliance requirements in an organization call for a structured methodology, which may prove to be counterproductive in Scrum environment.

Team along with the assistance of the Scrum Master should go ahead and define the required process for the Scrum practices to get implemented, this could include the way Sprint Backlogs are defined and maintained, or how continuous integration would occur in the project, or how and where the defects as reported would be logged, how the information from the sprint retrospective would be acted upon.

Scrum as such has few important ceremonies and a few important documents that help the development team and other stakeholders (e.g. PO) to run and execute the project as needed and required. It is important to us to remember that basic structure of agile scrum practices work in the area of “Delivering Working Software”

Planning and Organization

Scrum projects have 3 levels of planning, namely: Release, Sprint and Daily Scrum. In the Sprint and Daily Scrum, the development team has an important role.

By using the skills of planning and organising, the team will be able to get a lot more done, be able to meet deadlines and be able to demonstrate a shippable product increment. If the team plans and organises a sprint well, it results into a productive and positive experience for everyone.

For any project, it is required to understand the phrase “Expect the unexpected”. Be prepared to adapt or change your plans, in order to meet the situation on hand. Agile itself as a meaning means adaptability.

In the context of Self-Organizing, Self-Managed approach, with no project manager in the scope of things, planning and organizing becomes a lot more important, as the team needs to manage the sprint themselves. Organizing a work plan (sprint backlog in our case) with a team requires frequent, regular meetings. The meetings should address the overall goals of the sprint backlog, but there should also be a setting where feedback and amendments can occur. Team members should be able to voice their questions, concerns, and ideas regarding the sprint backlog.

A sprint backlog must have a timeline that is firm yet feasible. The team should know when they must complete certain tasks and duties. Also, many tasks cannot be completed until other tasks are completed beforehand. If your team is making GUI screens, the team members in charge of design must first design the screen before the other team members can develop it. Your timeline should be flexible enough to account for any setbacks the team encounters.

Set long and short-term goals for the team. Encourage feedback from the team members to help develop the goals for the team. Also, encourage the team members to set their own individual goals to help accomplish the larger objectives of the team. Every member should have specific goals for her task. This ensures tasks are completed thoroughly and on time. When the smaller goals are accomplished the larger goals usually follow

Decision Taking

With the pressure of having to make deliveries of working software every 2 weeks or at regular frequencies, Decision making / taking becomes a critical element for any development team. Decision making / taking is performed by the team at regular intervals, which would be at Sprint planning meeting, Daily Scrum, Sprint retrospective.

Each of the ceremonies of Sprint brings a different flavor of decision making / taking.

Sprint planning meeting requires decisions. Decision of what can be done in the given timeframe of the sprint, what commitments can be done by the team, to do the commitments; the team needs to decide, and based on its availability, skills, and resources what can be promised to the PO

Daily Scrum requires the decision taking ability with respect to the changes in the plans / approaches which would help the team to achieve and meet its commitments as given to the PO

Finally in the sprint retrospective, the team needs to reflect on what can be done differently and how it can achieve the same; they need to develop strategies to achieve the new approaches. The basic element of Inspect and Adapt needs to be working here.

In the next series of this blog, the last of the current series, we shall focus on the Scrum Master role in Scrum