Posted on

August 24, 2011 MONTHLY MEETING: Agile Risk Management with Sue Parente

MEETING VENUE: MICROSOFT offices in Waltham MA.
WEDNESDAY August 24 2011, 630PM

AGILE RISK MANAGEMENT

This presentation provides details on the methodology of risk management as it applies to Agile Software Development.

We go through the steps of identifying, assessing and managing risks.

As developers and managers, we have heard of risk management, but how much of it are we actually doing, and what is the impact?

This presentation is designed to engage you and provide tools which you can use for risk management inside your Agile projects.

ABOUT THE SPEAKER: SUE PARENTE

Susan Parente is a consultant, speaker, and mentor who leads large complex software implementation projects, and works in both the federal and private sectors.

Susan is project engineer and Adjunct Professor at Post University in CT. She has a BS in Mechanical Engineering from the University of Rochester in NY and has a MS in Engineering Management from George Washington University in DC.

She is also PMP, CISSP and ITIL certified, and is a CMMI and ISO 9001 Practitioner.

Ms. Parente is currently the Director of Professional Services of S3 Technologies, LLC. Her company’s focuses on revitalizing projects through the use of risk management. S3 Technologies does this by teaming with clients, stakeholders and vendors and using risk management to deliver software development project successes. Ms. Parente trains and mentors project managers in the area of project and risk management. She has developed a methodology which she uses to implement risk management programs for both small and large clients.

Posted on

Tacit vs. Explicit Knowledge

Explicit knowledge is knowledge that you can get out of a book, or a video, or a web page. It is A-B-C, 1-2-3, step-by-step knowledge. This is the knowledge found on Wikipedia, and similar resources like user guides, user manuals, and other books. This is the knowledge most of us understand from school, and other formal learning.

Tacit knowledge requires proximity and experience. It is not readily converted into book form. Knowledge about how to make sausage is a good example. You learn to do it by watching and by doing. Usually, you need a little coaching. It requires that you are communicating with someone that is watching you and coaching as you gain experience and competency.

On teams that build complex products, much of the team knowledge is of this tacit type. Having proximity to the engineers and testers, and listening and watching others who are competent in the craft is how you learn here. It is like watching sausage being made. Difficult differences and unsightly mistakes are part of the recipe in tacit knowledge creation.

Knowledge creation, like sausage making, can be difficult to watch.

 

 

Usually, substantial knowledge is held by the people in a team, the tribe or the enterprise. The knowledge– technical and cultural– is tacit.

A culture is this very real thing, yet it defies description. When you are in it, you are of it, and it affects you, and you get it. Yet it is hard to describe in writing or even to verbalize. The culture of a team, tribe or organization is the set of assumptions, the set of beliefs that are collectively held. It is not easy to reduce this to explicit knowledge.

You must “go to the gemba”, and visit, and get proximity to get a feel for what a team believes and understands about itself. Even then, explaining it accurately to someone else is tough.

In my book The Culture Game, I document a step-by-step, explicit-knowledge framework for scaling Agile, from teams to tribes. The book is intended as an A-B-C,  how-to manual, for the typical manager in the typical organization who wants to spread the essence of Agile. That essence is organizational (what I call tribal)  learning.

 

Posted on

Agile is a Game: Make it a Good One

A good game has 100% opt-in participation, a clear goal, a clear set of rules, and a clear way to track progress. Scrum has the potential to be a very good game.

The Scrum goal is “excellent results”. The Scrum framework rules are well defined, and are available in the current version of the Scrum Guide. And keeping score in Scrum is simple. We inspect the results at the end of each iteration, during the Sprint demo.

So, what is the missing ingredient to the good game recipe?

It is: opt-in participation.

We typically just hatch Agile on the very people who do the work. Is it any wonder we get push-back?

Agile and Scrum in the typical company is just hatched on the participants without any airing of what they want, what they think and what they feel. This leads to all sorts of problems. No one likes being compelled to do anything.

People Need to Be Heard

At NewTech, when we help a company adopt Agile, we sell and follow this plan: we do some training, and then we describe the use of Scrum as an experiment.

We do some iterations, saying, “we are trying Scrum as an experiment… so, let’s try it and see” .

Scrum as Mandate

You say you want self-organizing teams, yet you diminish any sense of control (and related happiness) with these absurd mandates-of-practices. You are telling people  “…we are going Agile. Scrum actually. Concerned? Confused? Let’s not go there. See you at 10AM at the stand-up.” Ugh.

Scrum is a un-satifying, not-fun game when you hatch it on people. You create automatic resistance because you kill any sense of control. People have to get heard. That hearing tends to make your Agile adoption a lasting one.

Don’t hatch Agile on people without a hearing. Doing so diminishes happiness by reducing sense of control.

We typically just go along, and proceed to literally hatch Agile on the people who do the work. This creates resistance. The result:  difficult, half-baked and yes, failed Agile adoptions.

Posted on

Scrum Language: the term Scrum “Master”

Here is something I get a lot when doing Agile coaching: I hear comments about Scrum terms and words. One of them is ‘Scrum Master’.

‘Master’ associates with acquisition of complete knowledge or skill. However, ‘master’ also associates with:

 

 

  • One having authority over another
  • One that conquers
  • One having control, especially over a slave or animal, also the employer of a servant

People who know Scrum know that the Scrum Master is supposed to be a servant, a servant-leader.

And that is the problem. Language frames reality.

Here is a term that refers to a servant as a ‘master’. I understand that Jeff and Ken mean the other kind of master, the master of a skill called Scrum. However, not everyone hears it that way. I know because I get comments on this matter and questions, all the time from Agile coaching clients new to Scrum. They are hearing “authority over”, “control over a servant”, etc.

Language matters !

Are you getting these comments and questions about the term ‘Scrum Master’?

Let me know.