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 that both developers need to write better code and management needs to lead complex development effectively 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.

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

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.

This past weekend I delivered a Scrum training course to unemployed people in Detroit. The name if this course was “Hard Times ScrumMaster Detroit”. This course has given rise to a concept we are calling HTU “Hard Times University”

HTU’s purpose is to deliver high quality, low cost, open source knowledge, current training, in a community driven way. It has clear to me that large parts of our educational system are simply holding our learning hostage by high price, huge loans and organizational patterns that create barriers to doing it any other way. The people in this course were amazing and the energy to drastically reduce these barriers is there. Expect to hear much more on “Hard Times University” in the upcoming weeks.

2nd

It looks like we have a couple of publishers interested in our book “Advanced Topi cs in Scrum“. Chapter 4 is ready to read and waiting for anyone who wishes to comment on it. Find it here CHAPTER 4

A great recent blog post by Vikas Hazrati caught my eye.

The story starts like this …

You have been feeling great. Recently, you met a lot of people in \the software community who knew little about Agile and you felt good telling them on how you are practicing Agile on your new project. You tell them about the wonders it has done to the business value delivered to the client and how your work life balance has improved since you started following Agile methodologies religiously. How you have felt so committed to the project that you are working on a that you have a great team of professionals.

So far so good.

The climax in the story comes on that dreaded Friday evening when the less committed people of the organization, which includes all of your team, are give the pink slip, and of course you are one of them!

You wonder, Why us, Why me, How the hell am I not committed? I thought that after years of developing software the wrong way this is the first time that you have done the things right, then why? The reason is that somehow your organization believes that you are not committed. Neither to the organization nor your work.

This is not a surprising outcome and all to common. Agile has gone mainstream but it will be attacked from many angles.

My Observations

The current systems are thought models, essentially living thought models, changing them is slow and painful.  Like any living thing when it is attacked or challenged it will fight back and lash out in fear, anger, igonorance and for pure simple survival. The people defending the old tired models of thinking are simple acting reasonable from their frame of reference.

Additionally, for big companies to even recognize that they have an incredibly valuable asset in a well formed team is a huge step acknowledge that performing teams are capital assets. With a great team I can deploy it towards a challenging business problem and generate a myriad of ways to thrive. Knowledge is a commodity, it is the ability to do something useful with that knowledge that will distinguish these companies long term. Eliminating your good teams (capital assets) from the business is fiscally irresponsible and it will come back to haunt the organization.

Expect real change to take years. You can do things to dramatically accelerate this change but, you have to be very thoughtful about your approach. It will not rely solely on a rationalized conversation (i.e. 1+1 = 2) people just don’t care when it comes to habits and perceptions driven from an emotional bases. And like it or not we are most often dealing with emotional issues since our rationalizations are anchored by an emotional part of our brain. Intentionally changing behavior is a long haul propositioin and the scrum framework is an means to inspect and adapt a change state into existence.

- Doug

http://3back.com

New Scrum User Group

I will be helping the  Ottawa Scrum User Group kick off its first Scrum User Group  meeting. User groups are something that are intreguging to me because they bring up issues of sustainable community structures. I will be curious to see what kinds of internal structure unfold , how they are put in place and how those structure lead to sustainability. I have helped and seen many local interest groups come and go. I have learned to appreciate just enough structure for a Scrum User Group. I am being sent by both 3Back and the Scrum Alliance at the request of Ottawa Scrum User Group. I will be delivering a short Scrum In A Nutshell talk. 

Why help?

Several reasons:  help local communities that are interested in Scrum, support the Scrum and the mission of the Scrum Alliance, work withlocally talented people to build a collaborative community, help my company 3Back and finally it is fun and helps me professionally. I am actively involed with the Scrum Alliance and have seen that growing  local Scrum User Groups, helps us all. 

Read the Scrum Alliance “Scrum User Group Guidelines“, getting started is easy and I can help.

1.) http://friendfeed.com/dailyscrum/a57c3474/scrum-users-group-controversy-agile

2.) http://www.infoq.com/news/2009/04/scrum-alliance-user-group

Context

“As discussed here previously, the Scrum Alliance plays an important role in helping to preserve the Scrum framework through its certification process. Because it has standardized the experience required for various “certified” positions in Scrum, the terminology used to describe Scrum, and, of course, the framework itself, the Alliance has armed thousands of software professionals with the practical knowledge they need to advance in a career in Scrum. I’ve always considered their work to be obviously valuable for individuals seeking training, but also an important reason why Scrum has flourished in recent years.”

Why

Scrum user groups, Agile user groups, XP users groups many of these I have seen come and go. I have tried and been unsuccessful at sustaining these groups and have seen similar patterns from others. However, I have followed others who were experienced and they have taught me.

It is my experience that these groups are driven by people who are not use to some necessary deliberate (self included) structure. Deliberate structure includes officers, organizing boards, keeping it interesting, volunteering, stimulating vibrancy and “marks (like SCRUMUSERGROUP)” from International organizations that help with credibility. These structures help groups sustain their existence. SPIN Groups have years of history, PMI groups have years of history, APLN has better success (different make up of people on average)Agile groups often seem to pop and die like grapes on the vine.

The Scrum Alliance is offering help by holding these marks and building brand value. Structure / value so that the group adopts some deliberate structure to stay organized enough to sustain it’s existence. We (agile community) need to learn from other groups that have a history and stop being so scared when something looks restrictive.

Doug Shimp
http://www.3back.com

• Project Management is mainly about “managing the work” or stimulating the environment so the work gets done with minimal telling people how / what to do.
• Source Control if it’s only one file then, I don’t need it of course it is always more than that as soon as it goes over 100 files it becomes a necessity.
• Build automation (and repeatable automated configurations as a whole) shows up after source control and becomes a necessity around 500(pick a number that you think you will go crazy at) items or so. It is a number thing but, I can get by longer without repeatable automated configurations than I can without Source Control.
• Test Automation this shows up as needed after 1000 plus code files. Test automation is all about feedback. When I say feedback it assumes people are already thinking in terms of interface design “start with the end in mind” if not then TDD/Unit must be purused because people are missing critical thinking skills.