Category: development

Posted on

What is a Hypothesis?

To understand what Hypothesis is and how we use the Hypothesis method we need some background information.

Let’s start, by learning about the Scientific Method.

The Scientific Method is a body of techniques for investigating phenomena, acquiring new knowledge, or correcting and integrating previous knowledge. To be termed scientific, a method of inquiry is commonly based on empirical or measurable evidence subject to specific principles of reasoning.

The Oxford Dictionary Online defines the scientific method as “a method or procedure that has characterized natural science since the 17th century, consisting in systematic observation, measurement, and experiment, and the formulation, testing, and modification of hypotheses”.

A hypothesis is a potential answer to the question, one that can somehow be tested.

The hypothesis is not necessarily the right explanation or the ONLY explanation. Instead, it’s a possible explanation that we can test to see if it is likely correct or how correct, or if we need to make a new hypothesis.

Experiments are a procedure (s) designed to test a hypotheses. Experiments are an important tool of the scientific method.  For a deeper understanding, you can watch a quick video here.

A box of Experiments

What I hope you see is that there is a direct connection between scientific method and the empirical processes of agile. There is no accident in the intentions of the scientific community and the agile community.  We are both based in the understanding that continual learning and adaption through hypothetical research and analysis is the best way to solve problems.

You may ask; “How can hypothesis-based learning help in solution development’?

To understand more clearly, let’s define a hypothesis, or a working definition we can use.

A working hypothesis is: a hypothesis is provisionally accepted as a basis for further research in the hope that a tenable theory will be produced, even if the hypothesis ultimately fails. Like all hypotheses, a working hypothesis is constructed as a statement of expectations, which can be linked to the exploratory research purpose in empirical investigation and is often used as a conceptual framework in qualitative research.

In agile, we talk about taking risk, failing fast, and learning.  These are all very consistent with the Scientific Method and the use of hypothesis.

There are also extreme cases of using this method as a form of Research & Develop in software and system solution development. There are corollary methods that further support these in large enterprises but know that the method is very popular in agile and your use of it will help your team drive innovation and new ways of solving problems.  Most importantly, it forces us to stop the ‘Big Upfront Design’ that so often hinders team’s abilities to do the right thing AND the best thing for the business.

When all is said and done, the use of hypothesis based work drives the most important part of agile and other solution development methods, it creates #learnings or #knowledge and we cannot ignore how important that is to teams and those who are charged with forming and leading them, as well as measuring their performance.

What is your theory? Are you putting it to the test in your daily work?

In future posts, I will expand more on learnings from Hypothesis Driven Development, and from Hypothesis Driven Improvement.

Thanks

Posted on

What makes agile, Agile?

The early founders of the ‘agile movement’ we’re just people who had been involved in solution development and just spent time thinking about how they could do their jobs better.  They spoke plainly and tried to use basic concepts that could guide their decision making and be repeatable.

Often in our daily lives we will tend to try to make ourselves look ‘smart’, ‘sophisticated’, ‘technical’, ‘innovative’ and so on.  usually to do this, we end up sounding like a lawyer or a professor from university.

On a recent trip, I had a chance to speak to farmers from another country.  In the US, we tend to see farming as a science now.  We use chemicals and computers and computer modeling.

As I spoke with these farmers they told me of how important weather was to them, and their planning.  The weather, or bad weather, could risk crops, animals and harvests as well as have negative and ripple effects on other planning.  In fact, they spent so much time telling me about the weather it was easy to see this information was extremely important to them and they would not risk getting it from a trusted source.

Interestingly, as the weather report came on the radio in the shop I was in, I noticed no one paid attention to the radio broadcast.  I found this really odd, as a tourist I was very interested in the weather too, and while I strained to hear and understand what was being said, they went about their business.

I asked the shop operator if he could help me by explaining some of the terms used in describing the weather better.  The operator, in a heavy accent, said ‘Nye’, if you want the weather accurately don’t listen to that ‘Uni’ TV guy, call up the postman.

Without a translator, I felt lost.  Why would I ask the man who delivered the mail about  the weather?  Did he get some special piece of information possibly controlled by the government to ensure mail delivery?  Was this kept secret from people who’s lives and livelihoods depended on it?  Why weren’t these farmers annoyed and alarmed?  It was very confusing.

As I returned to the tour bus I asked the local guide about this odd conversation.  The following is how it was explained to me, without the heavy accents and as little folklore as I can use!!

The local farmers had for years complained about the weather reports in the area.  They had become so frustrated with the accuracy that they even tried to remove the weatherman on the ‘telly’. He used to ouch science and words to make simple things complex and accuracy and precision were lost as he tried to impress with his explanation of ‘how’ weather was forming rather than getting the predictions correct and timely.  This problem lead to the ‘need’ for someone to step in and solve this problem.  Enter the ‘Postman’

Every day, after dropping the mail, a local man would go home and consult several pieces of information and create a file for the next day.  The file predicted sunrise and sunset, chances of rain, El Niña, La Niña  etc, winds and interestingly the tides, and predicted time times, as well as previously reported reports for the dates and accuracy of the reports.  Lastly of course was the high and low temps.

This man was not university educated, but rather spent time improving his craft through basic plan, do, check and adjust cycles.  Over time, he had become a local celebrity.  His passion for accurate weather reports, and experimentation with his own beliefs about what impacted weather lead him to form his own set of experiences and learnings.  He didn’t allow what he had been taught to always direct his reports, but instead spent time continuing to learn and adapt this thinking.  The goal was not the report, the goal was improving his own accuracy, incrementally, over time.

As I listened to the story I thought how agile of this man.  He took his simple principles and followed them, and then applied the data he had to make his next set of predictions about the outcomes.  He then recorded the outcomes, made notes about how his predictions had come out, then add any adjustments he felt necessary, repeated the process.  Maybe that is really Agile, not agile.

What is your experience? Are you being asked and are you doing, the right thing, right?

Posted on

Discipline vs. Process

In many organization when they decide to do an agile transformation it is typically to do either a process swap or ‘agile’ or scrum for waterfall.  Usually this is done with the noble goal of producing ‘business agility’.  The transformation should not be about the business, it should be about the people.

This misrepresentation is part of the common fallacy that causes many organizations to fail in their efforts or to get outcomes that do not measure up to their original business objectives.  This false objective causes organizations to focus their efforts on the wrong things.  The transformation should not be about the business, it should be about the people.  In the end, businesses are not agile, they can only employ people that embrace and exhibit agility.  These false objectives stem from some common misconception that process and discipline are the same thing and that discipline and agility are at odds with each other.

Webster’s dictionary defines these notions as follows:

Discipline:

  1. Control gained by enforcing obedience or order
  2. Orderly or prescribed conduct or pattern of behavior; self-control
  3. Training that corrects, molds, or perfects the mental faculties or moral character
  4. A rule or system of rules governing conduct or activity

Process:

    1. A natural phenomenon marked by gradual changes that lead toward a result: process of growth
    2. A continuing natural or biological activity or function such life processes as breathing
    3. A series of actions or operations conducing to an end; especially : a continuous operation or treatment especially in manufacture

Agility:

    1. The quality or state of being agile : nimbleness, dexterity

Clearly business cannot be nimble.  It is a collection of people and processes, nothing more.  However, the people can exhibit agility and cause the direction of the business and the activities of the business to exhibit the dexterity we associate with people.  To achieve that, we must concentrate on the discipline of the people, not the processes that control the business.

Agile is about people and unleashing their creativity and passions to drive outcomes.  Processes deliver consistent outcomes, agility drives unexpected outcomes that are directed to the objectives that are desired.  Discipline allows agility to learn in a consistent fashion that creates incremental and sometimes extraordinary increases on outcomes.

For a long time in IT we have sought to gain efficiency improvements in a very consistent way.  This approach fueled IT growth for a long time, but produced minor year over year gains but never really unleashed the significant efficiencies that can be delivered by the discipline associated with minor adjustments to how outcomes are achieved usually individual creativity and passion.

The connection between agile and discipline is very strong and the very best agile teams consistently use very disciplined approaches to their work so when outcomes deviate, they can trace the deviation, good or bad, to the trigger and can maintain very high confidence in how those outcomes were achieved, and repeat them or improve them.

Ultimately discipline, not process, is what allows agility, in people and in turn, businesses.  Your focus on doing the right things right is what will enable and unleash your agility.

Posted on

People vs. Resources

Human Resource Management may be the greatest misnomer in the history of all management activities.

This statement is not intended as a slight to the professionals who serve organizations by helping to acquire and keep talent, but it is a tacit recognition that we are all human. We are all part of the larger community and we all have basic needs and deserve to basic treatment as people.  We are not disposable, nor unfeeling. We all seek and need encouragement!

It is common now for many agilists to talk about the people not resources.

Recently a blog was printed here:

The Difference between Groups and Teams

By Jason Wick – March 1, 2018

Over the course of my career, I’ve contributed to teams across a variety of contexts. But not until the last year or two did I begin to understand what a team is and how this is distinctly different from a group. My realization was that most of the work I’d done had been as part of a group. The difference was not purely semantics; it was one of mission.

Currently I lead a cross-functional product team composed of several roles. Wherever personnel exist with multiple roles from different departments and management lines, there’s a risk of conflicting goals unintentionally working against each other.

There are several questions to explore here: What are the goals of the software engineers? What are the testers’ goals? Do these two lists present any unhealthy conflicts, or do they support a set of shared objectives?

As a simplified example, let’s say I primarily measure my testers’ value by tracking the number of defects they report. If that’s the case, I should be aware of the possibility that they may focus their energy on nitpicking in order to inflate their bug count rather than target their testing efforts with the customer experience in mind.

How does this relate to the differentiation between a group and a team? To first define them clearly in my own words, a group is a number of individuals working together to get something done, while a team is a set of people who share the same purpose. The team values its purpose above any specific goals related to roles.

If testers are logging a lot of defects to inflate their bug count and justify their value to their manager, we’re off base. If testers happen to log a lot of defects while serving a shared team goal of deploying defect-free software to its customers, we’re on the right track. But it also means the work of people in development and continuous integration must serve that same shared goal. In order to be a team, they all must approach their work with deploying defect-free software in mind.

Not every job to be done requires a team. There are plenty of times when a group does just fine. But I encourage you to take a hard look at your employees’ goals if what you’re aiming for sounds closer to the definition of team, where a set of individuals share their values and deliver with a unified purpose.

 

The authors recognition of the difference of belonging to a team vs. a group is somewhat a semantic difference, still important though.  As a group member I belong because of an attribute, rather than what I contribute.

Attribute:           Noun: a quality, character, or characteristic ascribed to someone or something has leadership attributes

Contribute:        Verb: to give (something, such as money, goods, or time) to help a person, group, cause, or organization — usually + to or toward

Think about that for a moment, as the member of a group, I cannot give my ‘male’ or ‘female’, my ‘tall’ or my ‘short’.  I can associate that attribute with that group. It requires no active relationship, it is emotionless and statistical.

Conversely, to contribute, I must actively participate.  In fact, I must ‘give’, which means be active and understand how I am providing benefit. 

When we see people as ‘resources’, we do not see them by their contributions, we see them by their attributions.  I am replacing this java developer with that java developer.  I am using this tester instead of that tester. The separation of will from action creates the notion of interchangeability and disassociation of cognitive actions, it takes away our humanity, our spirit, our drive and our passion.

Language is what gives us commonality.  Using it effectively to convey information is key to communication.  It also allows us to convey AND form emotions about the things we are discussing. When we remove the emotion of people by calling them resources it creates the false impression that we are all replaceable/interchangeable, but the reality is that we were all acquired because of our uniqueness, the skills we bring to the table, our passions and fears, our strengths and our weaknesses and our contributions are what make each of us special and integral to the teams we are part of, no matter what our group memberships may be.

Posted on

What is Servant Leadership?

Last weekend we saw the NFL coaching staff on the sidelines dressed in camouflage and other clothing that celebrated the military, in recognition of the sacrifices made by Veterans as well as to celebrate Veteran’s Day.

With the Veteran’s Day in mind, the focus this week is on servant leadership … there is no greater demonstration of servant leadership than the service to one’s own country.

What is servant leadership?

Skip Prichard notes that a Servant Leader is one who:

    • Values diverse opinions: A servant leader values everyone’s contributions and regularly seeks out opinions.  If you must parrot back the leader’s opinion, you are not in a servant-led organization
    • Cultivates a culture of trust: People don’t meet at the water cooler to gossip. Pocket vetoes are rejected.
    • Develops other leaders: It means teaching others to lead, providing opportunities for growth and demonstrating by example.  That means the leader is not always leading, but instead giving up power and deputizing others to lead.
    • Helps people with life issues: It’s important to offer opportunities for personal development beyond the job.
    • Encourages: The hallmark of a servant leader is encouragement.  And a true servant leader says, “Let’s go do it,” not, “You go do it.”
    • Sells instead of tells: A servant leader is the opposite of a dictator. It’s a style all about persuading, not commanding.
    • Thinks you, not me: There’s a selfless quality about a servant leader.  Someone who is thinking only, “How does this benefit me?” is disqualified.
    • Thinks long-term: A servant leader is thinking about the next generation, the next leader, the next opportunity. That means a tradeoff between what’s important today versus tomorrow, and making choices to benefit the future.
    • Acts with humility: The leader doesn’t wear a title as a way to show who’s in charge, doesn’t think he’s better than everyone else, and acts in a way to care for others.  She may, in fact, pick up the trash or clean up a table.  Setting an example of service, the servant leader understands that it is not about the leader, but about others.

In summary, servant leadership is about putting the needs of others first and helping people develop and perform to their highest potential. In the Agile world we look to the role of Scrum Master to be a beacon of servant leadership. The Scrum Master puts the team needs first and has the responsibility for protecting the team from external noise that may distract from the planned activities for value delivery while also fostering their growth and development.

Writer James Hunter explains how to become or hone your Servant Leadership approach in a book titled: The Servant Leadership Training Course.  In his book he states:

  • Servant leadership is a business philosophy that emphasizes the act of the leader, such as a manager or supervisor, focusing on the growth and development of their employees and ensuring their success. In doing so, the leader succeeds when their employees do. In a business team, servant leadership can not only help employees achieve and grow, but it can also benefit their leaders and the company as a whole.

He describes Leaders such as Ghandi, Dr. King, Mother Teresa and others. As you read the information below see if you agree that these people served others, and also led them. Then ask yourself if you do.
Hunter breaks Servant Leadership into three critical areas: Skill, Influence, Character

Leadership is the skill of influencing people to enthusiastically work towards goals identified as the common good, with character that inspires confidence!

    • Skill: A skill is something that can be learned or an acquired ability.
    • Influence: the capacity to have an effect on the character, development, or behavior of someone or something, or the effect itself.
    • Character: Moral maturity. Your ability to do the ‘right thing, even when no one is looking’.

The United States Marine Corps defines leadership as:

    • The qualities of moral character, that enable a person to inspire and influence a group of people successfully.

If you are interested in learning more about how to become a better servant leader, or you think you are ready to help, please let us know!