Empiricism

There are two types of process control

  • Defined Process Control – Plan driven way of doing things. Where the target (goal) is known, one can create a Plan and execute the plan.
  • Empirical Process Control – Goal driven way of doing things. In this type of problem, the solution or requirements or both are unknown. So, one has to take decisions on something which has already happened. So, the decisions have to be taken on trial and error way. Try something, see if it works, if it doesn’t work then try it another way. Too much of upfront planning is of no use in this type of process control

In Scrum, decisions are made based on Empirical Process control. In Scrum we try observation and experimentation rather than on detailed upfront planning.

Transparency

 Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy and transparent flow of information throughout the organization and creates an open work culture.

Inspection

 Inspection in Scrum is depicted through:

  • Use of a common Scrumboard and other information radiators
  • Collection of feedback from the customer and other stakeholders during the Develop Epic(s), Create Prioritized Product Backlog , and Conduct Release Planning processes.
  • Inspection and approval of the Deliverables by the Product Owner and the customer in the Demonstrate and Validate Sprint process.

Adaptation

 Adaptation happens as the Scrum Core Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing.

A Metaphor on Empirical and Defined Process Control

GROW Coaching Model

GROW is a proven coaching model to structure coaching experience .

beauty of this coaching model is that it leads to a clearly defined end result through four phases. The coachee is personally active in identifying problems and generating ideas for solutions. As the coachee is actively engaged, the outcome is more likely to succeed

The GROW coaching model encourages learning through experience: reflection, insight, making choices and pursuing them. The success of a coaching trajectory with the GROW coaching model also depends on the time and energy invested into the process by the coachee.

The best part about working with the GROW coaching model is that you don’t need to be an expert in a specific situation to be able to coach the team. This model offers a framework with general questions to elicit objectives , obstacles, options and more without ever needing to offer advice or force any particular direction.

The steps in the GROW coaching model

The GROW coaching model consists of four steps. The word GROW is actually an acronym for Goal – Reality – Options – Will. This GROW coaching model enables you to to plan a journey. You start with the map: where are you going (Goal) and where are you starting from (Reality)? It then charts the different routes and modes of transportation (Options). At last, it helps you pick the option that suits you best while still considering the obstacles on the way.

GROW coaching model – Step 1: Goal

The first step in the GROW coaching model is defining the goal of the coaching initiative at hand. You will need long term (the central theme ) and short term (the goal for every session)goals.

Goals need to be SMART: Specific, Measurable, Acceptable, Realistic and Timely.

Example questions to identify the goal:

  • What Will help us achieve defect free code?
  • Why a defect free delivery will benefit the team?
  • What it means to be defect free? How do you define it?

GROW coaching model – Step 2: Reality

Step two of the GROW coaching model is making coachee aware of the actual situation on the ground . The coache’s role here is to stimulate thought with the coachee, and to identify the obstacles that have been holding the client back.

It’s important to stay out of the equation in this phase; people have patterns and stories they can repeat and expand on endlessly. Keep on summarising and repeating what you understand from the coachee. Often, this phase of the GROW coaching model reveals underlying fears and convictions that can be worked on during or in between coaching sessions.

Example questions to discover the reality of one’s client:

  • Hows the code quality now?
  • How do you know the current code quality is poor?
  • Why is the code quality poor?
  • Why it is problem to have a poor code quality?
  • What are concrete examples of this problem?
  • What’s been going wrong so far?
  • Is this always a problem or are there situations in which it isn’t?
  • What have you done so far?

GROW coaching model – Step 3: Options

Step three of the GROW coaching model is to generate ideas that can contribute to the solution of the problem. Try to start a creative brainstorming process without censure or conditionality. Generate solutions, then structure it to evaluate every option. If needed, you can also offer some suggestions.

Example questions to generate options:

  • What else could you do to improve code quality?
  • What would you do if you did not have a hard time pressure ?
  • What else do you need to reach your goal? Where can you get it?
  • Which criteria will you use to evaluate this option?
  • What are the pros and cons of this option?

GROW coaching model – Step 4: Will

The fourth and last step of the GROW coaching model is the choice of one option. This is converted into a concrete plan of action. Then the coachee’s motivation to follow this plan is maximised.

Example questions to maximise the will:

  • What exactly will you do to improve the code quality and when?
  • Which of these options will you take?
  • What concrete step can you take NOW to improve the quality?
  • What steps come after?

Benefits Of Agile :: They may not be what you think.

We all know, Agile transformations can be incredibly painful…. In this article I want to explore why organisations are taking that pain. What are the benefits that organisations get by going agile?

Ask any organisation newly starting their agile journey, and they will say they expect time to market & cost to improve. In reality, the project duration of an increases because of the constant changes. Similarly execution cost is not always lowest agile, constant inspection and adaptation does have an overhead associated with it. Then what then are the benefits actually obtained by going agile?

Let us take a look at the some findings from 13th version one survey . This survey polled multiple stakeholders across geography, project type and associate seniority. 

We can see from the image above that, nearly 70% people find that rather than cost or time ti market, agile is helping them manage the changing priorities. In my eyes, this is the greatest advantage of agile bring to the table. Priorities are handled efficiently. The end users receive the features they want at a faster rate. This gives the feeling that time-to-market has improved.

Similarly, an Agile project encourages user requested features rather than the plan driven features. Because of this the team develops features that the users want.

Most organizations transitioning to agile see Improved quality. By definition an iterative process lends itself to better quality. More ever agile puts the focus of quality where it belongs – on the development team. This ensures that sub quality deliverable does not escape.

Better quality coupled with getting the features that the actually want leads to better end user satisfaction and indeed we should be the most important success criteria for any project!

Agile brings predictability. Management is usually happeist with this one key benefit. Delivery in a Cadence helps the management to know when the next feature is being rolled out. With prioritized execution, management can be sure that at any given point for a given cost the most important features would be implemented. 

Last but not least, agile helps with employee morale and job satisfaction. Ajay sports the development team in control of how the development is being done. This means employees now have the ability to self organise , they are empowered to take decisions and have more control over their working life. This increased control along with the emphasis paid on sustainable development mean that employees are now more engaged and more happy. Lofty goal for any organisation.

Benefits of DevOps

A sustainable, successful business is more than the development and operations teams. Limiting our thinking to just those teams who write software or deploy it into production does the entire business a disservice.

The 2015 State of Devops Report, published by Puppet, found that companies that are doing devops are outperforming those that aren’t. that an emphasis on having teams and individuals work together effectively is better for business than silos full of engineers who don’t exactly play well with others. High-performing devops organizations deploy code more frequently, have fewer failures, recover from those failures faster, and have happier employees. trend of focusing on outcomes rather than people and processes.

Focusing on the culture and processes encourages iteration and improvement in how and why we do things. When we shift our focus from what to why, we are given the freedom and trust to establish meaningfulness and purpose for our work, which is a key element of job satisfaction.

The introduction of devops has changed our industry by focusing on people and processes across roles to encourage collaboration and cooperation, rather than competing with specialization.

As we said, our goal as software professionals is to deliver useful, working software to users as quickly as possible. Speed is essential because there is an opportunity cost associated with not delivering software. You can only start to get a return on your investment once your software is released.

DevOps principles can also be applied to the business

DevOps is not just support IT. DevOp scan also be used to support the business strategy and to improve business processes. DevOps applies agile and lean principles across the entire software supply chain. It enables a business to maximize the speed of its delivery of a product or service, from initial idea to production release to customer feedback to enhancements based on that feedback. Because DevOps improves the way that a business delivers value to its customers, suppliers, and partners, it’s an essential business process, not just an IT capability.

Enhanced customer experience

Delivering an enhanced (that is, differentiated and engaging) customer experience builds customer loyalty and increases market share. To deliver this experience, a business must continuously obtain and respond to customer feedback. This requires mechanisms to get fast feedback from all the stakeholders in the software application that’s being delivered – customers, lines of business, users, suppliers, partners, and so on.

In today’s world of systems of engagement (see “ Understanding the Business Need for DevOps ,” earlier in this chapter), this ability to react and adapt in an agile manner leads to enhanced customer experience and loyalty.

Increased capacity to innovate – Repeatable, reliable, and predictable

Modern organizations use lean thinking approaches to increase their capacity to innovate. Their goals are to reduce waste and rework and to shift resources to higher-value activities.

Faster Time to Value

Speeding time to value involves developing a culture, practices, and automation that allow for fast, efficient, and reliable software delivery through to production. DevOps, when adopted as a business capability, provides the tools and culture required to facilitate efficient release planning, predictability, and success. The definition of value varies from organization to organization and even from project to project, but the goal of DevOps is to deliver this value faster and more efficiently.

Companies using DevOps are outperforming those who are not

Lot of studies have proved that the companies who are using DevOps outperform the ones who do not. The 2015 State of Devops Report, published by Puppet, found that companies that are doing devops are outperforming those that aren’t. that an emphasis on having teams and individuals work together effectively is better for business than silos full of engineers who don’t exactly play well with others.

Myths About DevOps

The DevOps movement is young and still emerging, especially among enterprises. Like any new movement or trend, it has attracted myths and fallacies. Some of these myths may have originated in companies or projects that tried and failed to adopt DevOps. What’s true in one situation, however, may not necessarily be true in others. Here are some comm. on myths about DevOps — and the facts:

DevOps Is Only for Web based organizations

What is generally referred to as DevOps originated in “born on the web” companies (companies that originated on the Internet) such as Etsy, Netflix, and Flickr. Large enterprises have been using DevOps-aligned principles and practices to deliver software for decades, however. Furthermore, current DevOps principles, have a level of maturity that makes them applicable to large enterprises that have multiple-platform technologies and distributed teams.

DevOps Is Operations Learning How to Code

Operations teams have always written scripts to manage environments and repetitive tasks, but with the evolution of infrastructure as code, operations teams saw a need to manage these large amounts of code with software engineering practices such as versioning code, check-in, check-out, branching, and merging. Today, a new version of an environment is created by an operations team member by creating a new version of the code that defines it. This doesn’t mean, however, that operations teams need to learn how to code in Java or C#. Most infrastructure-as-code technologies use languages like Ruby, which are relatively easy to pick up, especially for people who have scripting experience.

DevOps Is Just for Development and Operations

Although the name suggests a development-plus-operations origin, DevOps is for the whole team. All stakeholders in the delivery of software — lines of business, practitioners, executives, partners, suppliers, and so on — also have a stake in DevOps.

DevOps Isn’t for ITIL Shops

Some people fear that DevOps capabilities such as continuous delivery are incompatible with the checks and processes prescribed by the Information Technology Infrastructure Library (ITIL), a set of documented best practices for IT service management. In reality, ITIL’s life-cycle model is compatible with DevOps. Most of the principles defined by ITIL align very well with DevOps principles. ITIL has, however, received a bad reputation in some organizations due to being implemented predominately with slow, waterfall processes that didn’t allow for rapid changes and improvement. Aligning such practices between development and operations is the essence of DevOps.

DevOps Isn’t for Regulated Industries

Regulated industries have an overarching need for checks and balances and for approvals from stakeholders who ensure compliance and auditability. Adopting DevOps actually improves compliance, if it’s done properly. Automating process flows and using tools that have built-in capability to capture audit trails can help. Organizations in regulated industries will always have manual checkpoints or gates, but these elements aren’t incompatible with DevOps.

DevOps Isn’t for Outsourced Development

Outsourced teams should be viewed as suppliers or capability providers in the DevOps delivery pipeline. Organizations should ensure, however, that the practices and processes of the supplier teams are compatible with those of their internal project teams. Using common release planning, work-item management, and asset repository tools significantly improves communication and collaboration between lines of business and supplier and project teams, enabling DevOps practices. Using application release management tools can greatly improve an organization’s ability to define and coordinate the entire release process across all participants.

No Cloud Means No DevOps

When you think of DevOps, you often think of cloud because of its ability to dynamically provision infrastructure resources for developers and testers to rapidly obtain test environments without waiting days/weeks for a manual request to be fulfilled. However, cloud isn’t necessary to adopt DevOps

DevOps Isn’t for Large, Complex Systems

Complex systems require the discipline and collaboration that DevOps provides. Such systems typically have multiple software and/or hardware components, each of which has its own delivery cycles and timelines.  DevOps facilitates coordination of these delivery cycles and system-level release planning.

DevOps Is Only about Communication

There is a misconception that communication and collaboration solve all problems. DevOps depends on communication, but better communication coupled with wasteful processes doesn’t lead to better deployments.

DevOps Means Continuous Change Deployment This misconception comes from organizations that deploy only web applications. The concept here is about being ready to deploy when the business thinks it is the right time and not when the code is ready.

Power Questions – A really powerful technique

An agile coach is an influencer and not an enforcer. This means he does not get to dictate what approach a team will choose. In agile, development team decides what and how of their actions! In such a situations, asking leading or probing questions is one of the most powerful tools in the coaches arsenal

What Are Power Questions?

If you ask the wrong questions, even incomplete questions, you’ll probably get a wrong answer, or at least not quite what you’re hoping for.

Asking the right question is at the heart of effective communications and information exchange. By using the right questions in a particular situation, you can often make the recipient reach the conclusion you want them to. . Rights questions will help you gather better information and learn more, build better relationships and help others to learn too.

Following are some type of questions and also some guidance on when to use and when NOT to use them.

Some Important Power Questions?

Open and Closed Questions

A closed question usually receives a single word or crisp , Boolean answer. For example, “Was the sprint on time?” The answer can only be “Yes” or “No”; “How many defects did we have?” The answer is generally a number.

Open questions encourage more in depth answers. They usually inquire about elements of what, why, how. An open question asks the recipient for his or her knowledge, opinion or feelings. This engages the recipient in more constructive manner “Tell me” and “describe” can also be used in the same way as open questions. Here are some examples:

  • What did you observe in sprint planning?
  • Describe how your typical daily scrum goes…
  • Tell me about your feeling about this issue
  • Why do you think the sprint had so many quality issues?
  • How did he react to that?

Open questions are good for:

  • Initiating an open dialog: “What was your experience with automating system test?”
  • Provoke thought : “What else do we need to do to make this a success?”
  • Finding out the other person’s opinion : “What do you think about those changes?”
  • Collect more details “Was there something else that we need to know?”

Closed questions are good for:

  • Testing understanding, yours or the recipient’s: “So, if I get this automation done, build wont break?”
  • Ensuring that everybody is on same page “Now we know the facts, are we all agreed this is the right course of action?”
  • Creating a background: “Are you happy with the code quality?”

A misplaced closed question, on the other hand, can kill the conversation and lead to awkward silences, so are best avoided when a conversation is in full flow.

Funnel Questions

This technique involves starting with general questions, and then funneling down to a more specific point in each. Usually, this will involve getting in more and more detail . Detectives often use this techniques while taking statements from witnesses

“How many people were involved in the fight?”

“About ten.”

“Were they kids or adults?”

“Mostly kids.”

“What sort of ages were they?”

“About fourteen or fifteen.”

“Were any of them wearing anything distinctive?”

“Yes, several of them had red baseball caps on.”

“Can you remember if there was a logo on any of the caps?”

“Now you come to mention it, yes, I remember seeing a big letter N.”

Using this technique, the detective has helped the witness to re-live the scene and to gradually focus in on a useful detail. Perhaps he’ll be able to identify young men wearing a hat like this from CCTV footage. It is unlikely he would have got this information if he’s simply asked an open question such as “Are there any details you can give me about what you saw?”

Tip:

When using funnel questioning, start with closed questions. As you progress through the tunnel, start using more open questions.

Funnel questions are good for:

  • Finding out more detail about a specific point: “Tell me more about Option Two.”
  • Gaining the interest or increasing the confidence of the person you’re speaking with: “Have you used the IT Helpdesk?,” “Did it solve your problem?,” “What was the attitude of the person who took your call?”

Probing Questions

Probing questions is another strategy to get to depth of an issue. Sometimes it’s as simple as asking your respondent to elaborate “I did not understand your point about automation , can you please expand?” At other times, you need additional information for clarification, “When do you need this report by ?” Or to ascertain facts about what has been said, “How do you know that the new database can’t be used by the sales force?”

An effective way of probing is to use the 5 Whys  method, which can help you quickly get to the root of a problem.

Tip:

Use questions that include the word “exactly” to probe further: “What exactly do you mean by fast-track?” or “Who, exactly, wanted this report?”

Probing questions are good for:

  • Gaining clarification to ensure that you have the whole story and that you understand it thoroughly.
  • Drawing information out of people who are trying to avoid telling you something.

Leading Questions

Leading questions try to lead the respondent to your way of thinking. They can do this in several ways:

  • With an assumption – “How late do you think that the project will deliver?” Here you assume that the project will certainly be late !
  • By adding a personal appeal to agree at the end – “Lori’s very efficient, don’t you think?” or “Option Two is better, isn’t it?”
  • Phrasing the question so that the “easiest” response is “yes” – People naturally prefer to say “yes” rather than “no”. This psychology plays an important part in the phrasing of questions: “Shall we all approve Option Two?” is more likely to get a positive response than “Do you want to approve Option Two or not?” The “shall we” part of the questions brings you and respondent in one group while the “do you” puts the respondent in opposite camp.
  • Giving people a choice between two options – both of which you would be happy with, rather than the choice of one option or not doing anything at all. Strictly speaking, the choice of “neither” is still available when you ask “Which would you prefer… A or B?” but most people will be caught up in deciding between your two preferences.

Note that leading questions tend to be closed.

Leading questions are good for:

  • Getting the answer you want, but leaving the other person feeling that they haven’t got a choice.
  • Closing a sale: “If that answers all of your questions, shall we agree on a price?”

Tip:

Use leading questions with care. If you use them in a self-serving way or one that harms the interests of the other person, then they can, quite rightly, be seen as manipulative and dishonest.

Rhetorical Questions

Rhetorical questions aren’t really questions at all. They they don’t expect an answer. They’re really just statements phrased in question form: “Isn’t John’s design work so creative?”

People use rhetorical questions because they are engaging for the listener – as they are drawn into agreeing (“Yes it is and I like working with such a creative colleague”) – rather than feeling that they are being “told” something like “John is a very creative designer.” (To which they may answer “So What?”)

Tip:

Rhetorical questions are even more powerful if you use a string of them. “Isn’t that a great display? Don’t you love the way the text picks up the colors in the photographs? Doesn’t it use space really well? Wouldn’t you love to have a display like that for our products?”

Rhetorical questions are good for:

  • Engaging the listener.
  • Getting people to agree with your point of view.

Critical Success Factors of DevOps

As I had described in the introductory post, DevOps is about a cultural and mindset change. It is not about just implementation of a few tools and techniques. Any type of culture change involves a number of critical success factors.

In the context of DevOps these include:

  • Management commitment to culture change : Without a Management commitment, it is hard to imagine a cultural shift as big as DevOps
  • Creation of a collaborative, learning culture : This is a continuous learning culture which involves improvement of processes, tools and the work that one does.
  • Common values and vocabulary
  • Systems engineering that spans Dev and Ops
  • Meaningful metrics : Sometimes organizations have metrics which are not in sync with the actual work going on on the floor. The metrics have to be meaningful
  • A balance between automation and human interaction : Most people think DevOps is about Automation only.
  • Application of agile, lean and service management methods
  • Open and frequent communication

Choosing right agile pilot

Many students ask me how to choose a pilot? To ensure success of your transformation, it is really important to choose a right pilot. Below I will give  a few suggestions. These suggestions have worked for me in while choosing an Agile pilot.

  1. Select a “Visible but not critical project”. It is important to choose a project that has visibility across organisation. This will make the next steps of spreading agile easier. When we select a visible project, it becomes difficult for detractors to dismiss the success. At the same time be wary of selecting mission critical projects. Too much is riding over success of such a project. In this case, the team will be less likely to experiment. The stakeholders will be even less likely to have the necessary patience.
  2. Size Matters!! I usually suggest to select project which is not too large. A large project has additional scaling challenges. These become  an overhead while trying to implement agile. Usually not more than 3 scrum teams is a nice rule of thumb to follow. I also caution against selecting a too small a team. Such project may also mean a success which is not as spectacular to be tooted across organisation. A really small project delivered by a small team is anyway likely to be succeeded and agile would not get the crredit for the success!
  3. Where possible avoid added complicating factors. If at all  possible, it is better to avoid a project with unnecessary complications.Some examples can be, technology which is too strange to the team , a team that is greatly distributed (more that 3 locations)  or a team that is too new and still in “forming /storming” stage. Changing way of work to Scrum is anyway stressful, it is best to avoid further stress. 
  4. Select a project that intuitively needs agile It’s best to select a project that has need to evolve requirements – in other words it’s best to have a pilot for starting a brand new product. It will allow the inherent agile qualities to shine..At the same time, we would avoid added complications of a monolithic architecture or a legacy code base that no one fully understands.
  5. On board the champions – Identify your supporters early and include them in your pilot. These people are any way convinced and they will work hard to prove the concept.
  6. Avoid The detractors – In the same vein, it is usually prudent to avoid strong nay sayers. They usually will come on board when they see the pilot succeed. This will reduce the stress of having resistance along every step of pilot

Difference Between Agile Coaching Mentoring and Agile Training

A scrum master needs to be skilled in Coaching, Mentoring as well as Training. Each of these activities have a considerable overlap. Each involves helping people to improve their performance.

Training

Training involves an expert (trainer)imparting a certain knowledge or skill to other people (trainees). A trainer is not usually involved in day to day activity. Its a structured activity revolving around sharing the said knowledge or skill.

Mentoring

Mentoring on other hand,  is a system of semi-structured guidance whereby one person shares their knowledge, skills and experience to assist others to progress . Mentors usually are SMEs or experts who have traveled the path before and possess answers that will help the mentee. Coaching

Coaching

Coaching is a form of development in which a coach supports a learner in achieving a specific personal or professional goal. In other words, coaching is about a Coach unlocking the potential of the coachee. Here the coach may or may not have the answers. His role does not include handing over the answers on a platter. The coach helps the coachee to discover the answer himself.

How Agile Coaching, Agile Mentoring and Agile Mentoring differ?

A skilled scrum master needs to understand the difference between the three activities. He needs to be able to use the right tool for right situation. I have tried to list the key differences below.

 What is It?Duration & RelationshipWho Drives it?ModelsGoal
Agile TrainingImparting new skills
Or knowledge to the trainees
Usually short term. Is a transnational activity . Training is normally one to many where each trainee participates in individual capacityTraining is driven by the trainer - He/She decides the methodology and the model of the trainingMultiple models like classroom instruction , discussions , demonstrations , hands on exercises may be usedIncreased Skill or Knowledge for the trainee(s)
Agile MentoringHelping the mentee to reach the answers and achieve towards a certain goalUsually Long term. Its an ongoing hand holding till the mentee reaches the goal.Mentor , who is SME drives the direction and modelMore intimate one on one way extended via discussion or thought provoking questions. Mentor will help the mentee outline his options and choose oneBetter clarity for mentee
Clear plan of progress
Agile CoachingDevelop existing skills to enable the team reach a better stateUsually medium term - lasting a few months to couple of years

Agile coaching is usually in a one to many form where the coachees participate as a team
Here the coachess are the ones in driving seat. Coach will subtly influence but he can not enforce the way a coaching goesCoaching usually happens where coach helps the team to reach a stage where they them selves will find the answerBetter on the ground application on skills and knowledge

Agile Coaching

With so many organizations adopting agile, “agile coach” has become a very important and in demand role. In industry today we see a common confusion around this this role. What does an agile coach do? What do you actually mean by agile coaching? These are the questions with many scrum masters struggle.

In this section, I am planning to write about my perspectives about agile coaching , what skills are needed by a good agile coach. What are some effective techniques to use?

Stay tuned and read along