The program is off to a great start and seems to be generating the right kind of focus. If the CSD Program can bring or highlight the skills developers need to write better code and management needs in order to enable the developer then it is doing the right thing.

Each certification program from the Scrum Alliance comes with it’s own challenges and risks. Sometimes it appears to be  just a stamp that says you know something. Right now it does behave that way but, it also continues to bring a focus on what is really helping companies develop better products by humanizing the process. The days of classic command as control paradigms are being replaced with smart adaptive strategies that enable the discovery of real solutions to challenging problems. I am optimistic that the Certified Scrum Developer program will be a success and see a major boost this year from the Scrum Gathering conference.

I am excited by the gathering because I get to interact with my peers. They always challenge me and teach me. The  Scrum Alliance has been a great place for growing a community deeply passionate about applied agile practice and growing many new thought leaders in agile.

Hope to see you there this year or next.

It is really not a choice so much as it is a discussion about how they can re-invigorate their very agile roots. Agile is not yours to keep, to remain agile you must practice the fundamentals. Microsoft has clearly been very agile in the past and acquired very agile organizations. My question becomes — How do they get it back or get it again?

The video is found here.

My comments follow

The word Agile:  We can take it in different ways for different people but, from what I have experienced it is often a mess in understanding. There are very few good stable definitions out there from which to build a know center of understanding. Too often marketing has taken hold of the word and warped it’s meaning for personal gain. Or agile “experts” have not really nailed the term down to anything stable. Nothing is wrong with that, it’s just good business or people learning. However, the result is that it permeates a very messy set of understandings into the community at large.

Clean code and clean tools allow for rapid feedback which enables a quick practice of agile understanding. A good IDE will enable rapid feedback so that the fundamentals are practiced continuously. When I use the word fundamentals it is like in basketball. You are never done dribbling the ball. Unit tests are a way to achieve rapid feedback but, like all of the agile practices not a panacea. Unit testing is a piece to a bigger evolving puzzle.

Common mistake when people view Microsoft is too see it as one company. My experience is they made up of many subgroups or companies within a larger framework. Some subgroups are very agile and some are not. The agility is not evenly distributed and understood within Microsoft. No surprise there, every big company I have consulted with has this problem. Some groups (teams and individuals) within Microsoft are great agilists, not all. They have some of the best in the world.

It was a good quick talk on adopting scrum and agile.

- Doug

The conversation went something like this.

“People who know they are being assessed will pay more attention in a training course or at their daily work. We need to use exams and assessments to getthem to pay more attention because otherwise they will just flake off. People are inherently lazy and we need to make sure they work.”

The conversation above sounds like a hidden threat. The threat I see goes something like… If you miss something you are in trouble on the exam or “Pointy Haired Dude” is watching…. This is an old school paradigm that destroys critical thinking in my experience. For example, the issue of an Exam has dogged classic PMP training and has generally pulled down the quality of critical thinking across the spectrum of corporate environments. It dogs classic workshop training when the conversation moves from “whats the best way to think about this ….. to ….. will this be on the Exam? If not on the exam then, can we move on to stuff that will be on the exam?”

When people become more concerned about the exam or assessment they have often stopped thinking critically. For agile training, which is most of what I do these days, people can easily fall back to old learning styles of known answers to known questions. Most of today’s business problems are demandingly complex and do not have predictable outcomes. A test or exam is a simple predictive Q/A model and that includes the situational stuff as well. For situational stuff, I just memorize the abstract pattern for which the situational question is written for and then answer according to the pattern. To deal with complexity people need an empirical thought process for the finding stuff we don’t know we don’t know. Cramming more factoids into adult heads is counter productive. As adults we typically have more than enough information crammed in our heads. The question becomes “Can we make better use of what we already know or have experienced to deal with uncertainty?”

In my experience, open reflective learning will occur and empirical behavior will result when, as a trainer/leader to I make the environment safe for learning. As a manager/director of people the same policy holds true, if you punish people for making mistakes they will stop making mistakes by trying not to do to much beyond what is painfully obvious that needs doing. In either case, learninig is shut down for knowlege workers. Sharing of knowledge, both tacit and explicit, comes to a halt and the organization’s ability to learn atrophies because those muscles are no longer being used. At this point the best we can achieve is a pursuit of efficiency and what you find is a focus on faster / cheaper / quicker. Anything that is different and innovative gets squeezed out by the fear of not doing something that is well understood and controllable.

Innovation is needed across most areas of today’s corporation. Learning should be part and parcel to every engaging job and challenge. For innovation to occur people need to focus on learning and that means expect mistakes. If they do not feel safe they will make feeble attempts to do some new things but, never really bravely reach out of their comfort zone. If you are hiring for factory / robot type positions then expect robots but, knowledge workers are key for innovative culture and fresh ideas.

People in my workshops pay attention because they care and I care. It is a social bond. As a leader/trainer you set a behavior pattern that will be modeled. Are you modeling “I am watching you!” ? People that work/report to me pay attention because we both care to do the best. Those that don’t care can and should be asked to leave or excuse themselves until they sort out their destructive tendencies. I call not caring destructive because it destroys empirical behavior .

Generally, it is useless to retain people that do not care. In most cases the overhead of managing them is in excess of not having them there. Which sadly means I am better off doing the job myself. As a leader or trainer your first job should be to foster an atomosphere where learning is safe and encourage your people to become learning machines. Better teams make better people who make better products.

• At the forefront of learning is where innovation occurs.
• Learning is about knowledge creation (see Nonaka’s paper).
• Knowledge creation is an interactive process.Organizations that foster learning reach new heights.
• People that are in learning mode are paying the best kind of attention.
• A good scrum process enables the team learning process.

Maybe I am completely off my rocker but, I found the conversation interesting.
Comments?
- Doug

VersionOne was kind enough to invite me as a presenter to a small conference event in Austin on December 7th 2009. The Austine keynote went well and I was lucky enough to be ranked as the best presenter at the event. There were 90+ people in attendance and 78 people filled in an evaluation.

Catch me in Austin, TX delivering a Keynote for the Agile Journal December 7th,  http://www.accurev.com/seminar/austin20091208-4

Kanban for software development is a newer kid on the block, at least in the US. Besides being just another word like Scrum that is not commonly understood in the English language, how does it stack up? Both Kanban and Scrum align with the well with the value system described in the Agile Manifesto. And they make an interesting pair.

As much as we love Scrum, even we would have to admit that it’s not perfect.  Nothing is. In fact, a large part of the literature describes workarounds for various deficiencies that Scrum presents to us in certain circumstances.

One of the more commonly noted deficiencies in Scrum is that it plans its work a whole Sprint at a time.  This “batch” planning process is often not agile enough to cope with the actual rate of change of requirements.  In fact, PlaceHolder Stories, discussions of mid-Sprint Re-planning, and discussions of renegotiating the scope of a Sprint are common deficiencies that teams must cope with.

The new kid, called Kanban, which solves some of these deficiencies and presents others, is becoming popular for software development projects.

Altogether, Kanban, Scrum, XP and many other agile methods rely on a task boards and index card like systems to simultaneously decompose and manage the work. What’s new about task boards and index card systems? Index card systems have been around at least since 1925, when the first one was formalized by Dr. Crawford and used later to build NASA rockets. Increasing task orientation is a well understood method for improving team performance and has been well documented since the 1950s. Our goal will be to highlight both Kanban and Scrum and then touch on why we need to reinvent them ourselves so often.

Learning Objectives

• An overview of Kanban
• An overview of Scrum
• Stacking them side by side
• The Power of Index Card Systems and Task Orientation
• Can one reduce or evolve from one to the other?
• Why do we repeat ourselves so often?

Discussion: The word self organizing is a little fuzzy for me.

The way I think about self organizing teams is that they are  pre-assembled. After assembly a pressure is applied to respond to a demand. The demand is articulated
in the form of a story/project (don’t want to dice those words right now!) And the pressure is from a business that provides support as long as … You produce something of value! “Eye on the Prize”

The demand is applied such that we get feedback. That feedback has a sensitivity that can be adjusted or tuned like a dial. The dial for agile/scrum teams is easily seen in the form of a story (Chunk of Work) level  and can go up to the thickness of a project/product. If the demand goes unfulfilled then there is an implied threat of dissolution against the team or even loss of job individually.

Sometimes the support is so strong that we can ignore the demand and turn our noses up in the air. Big government / orgs often feel like that to me. It just do not matter because nothing bad will really happen so why sweat the small stuff. Even if that is not true and something bad will happen if it feels like nothing bad will happen then the behavior often develops a “don’t sweat the small stuff” approach.

Is self organizing the best way? I think that depends if it humanizes the workplace and makes better people with more compassion while igniting creativity to help the business thrive. Demands must be seen as real and consequences for failing to work well with others must be imposed.

1. No way, they are opposites
2. Kanban is for flow / Scrum batch
3. Yes, Scrum is old school big planning steps
4. Kanban minimal planning / Scrum is heavy planning
5. No, Scrum can reduce to KanBan

As much as we love scrum, even we would have to admit that it’s not perfect. Nothing is.  In  fact, a  large part of our book describes workarounds  for various deficiencies that scrum presents to us in certain circumstances.

One of the more commonly noted deficiencies in scrum is that it plans its work a whole Sprint at a  time.   This “batch” planning process  is often not agile enough  to cope with the actual rate of change of requirements.    In fact, Chapter 4.4 on PlaceHolder Stories, the  discussion  of  the  mid-Sprint  Re-planning  in  Chapter  4.8,  and  the  discussion  of renegotiating the scope of a Sprint in Chapter 4.3 are all about resolving this deficiency.

There  is  another  agile  process,  called  KanBan,  which  solves  this  problem  and  is becoming popular  for  software development projects.  In our upcoming book we will describe the main strength of KanBan and how to integrate it into scrum.

Brief Description of KanBan

The  “KanBan  for  software” movement  is  really gaining some  traction  in  the  agile  community.    The main  idea  of  KanBan  is  very  simple  and based  on  the  Lean  “pull,”  “Just  in  Time”  (JIT),  and  “reduce  inventory”  principles:  eliminate planning inventory by making sure that you don’t commit to doing work until you are actually ready to start the work.

1. The PO says go.
2. The Teams says they are ready.
3. The SM has determined a time box for the sprint.
4. The team and PO agree to a time box
5. The PO understands and is prepared to talk about the stories

Comment: There are a number of things you should do before you can even begin planning.  The most important thing you can do is make sure that your Product Owner is prepared, and understands what the stories are about.  Remember that the Product Owner is a role here, so what we’re actually saying is that someone on the Team knows about each story; that is, each story has its own champion (Story Owner) who represents the Stakeholder’s needs/wants to the Team. This may require that the Product Owner (person) coordinates the efforts of all the Story Owners.

Comment: Changes to work forms an interesting tension.  At a fine grained detailed level it changes all the time. Each person’s individual to-dos often change toreflect their understanding of what it takes to get the job done. As the level of granularity increases to task then it is a change to the team’s plan. If the number of changes is significant and adds up to more than one story’s worth of work then you better stop and adjust your plan, usually you want the product owner in on that discussion. And if there are several new  stories that were  suddenly found and are so important they must be done right now, then call a stop and reset your entire sprint with a sprint planning session. Generally, the commitment by the team to the sprint should not change. Note: definition of team makes this an interesting discussion. Bottom Line: The goal here is to help the team get better at  expressing work they can do and following through on a commitment.

Comment: The idea here is that there can be only one source for Scrum knowledge. I guess that depends on where you get your definition from and what you need. Should there be only one way to think about scrum? Probably not, although,  a rookie mistake is to modify without have deep applied practice and experience under your belt. The 1st common mistake we see people make is modifying scrum without understanding it. They often confuse themselves and their organization.