Over the past 3 years Ken Schwaber and Gunther Verheyen have established a firm working relationship. They created and shared many ideas on Scrum, its promotion and utilization, and ways to improve the understanding of Scrum in the software industry.

Ken and Gunther recently decided to tighten the relationship even more. As from June 2013, Gunther will join Scrum.org as Director of Professional Programs. Gunther will be Director of the Professional Programs, including the courseware and assessments for the PSD, PSM, PSF, and PSPO programs. He will also promote Scrum in Europe, contribute to the Enterprise Scrum program, and be an active member of Scrum.org.

Ken and Gunther express their profound belief that their highly collaborative partnership will be highly beneficial. They join forces to increase the measurable impact that Scrum.org aims to have at the improvement of the software development business.

Ken

Speaking of selling chickens still in shells, an august panel of industry giants laid out their recent improvements and plans for ALM products (Application Lifecycle Management, for those not in the know). These guys dazzled the audience with how they’ve moved far beyond simple source code repositories and testing tools to a complete integration of all modern software practices. Quite a coup, indeed, since most real live software developers I’m seeing out there today still aren’t using the practices automated by the ALM tools. Jeffery Hammond from Forrester sees it the same way. He polled software developers and found 18% didn’t even use source version control. Another industry insider later told me he’d polled the people at his talk about testing: How many of them used test driven development, acceptance test driven development, OR behavior driven development? Note his was an OR question, not AND, and that everyone in the room developed software for a living. Only three out of the some 100 people in the room raised their hands.

In other words, many software developers aren’t using practices such as test driven development or source version control. Yet here are HP, Microsoft, and IBM announcing new ALM tools that automate more advanced practice in areas not even in use in the first place. Unbelievable.

If more of the software developers complied with the practices needed to develop a complete increment of software, we might have something to automate. They don’t, so there are few practices to automate.

And this is when ALM industry revenues are $5-7B per year. Rather than pushing the next iteration of ALM for future use, let’s put these revenues to work now helping developers learn how to use modern practices. Further, this money should go toward creating work places where these practices are encouraged, perhaps even mandatory.

So, perhaps, ALM has the cart before the horse? Who knows? I’ve had my head down working with developers for so long I may have missed something, like that Agile 2.0 release that snuck by me.

Ken

We live in a complex society where software is increasingly used to improve efficiency and create connectivity. Thanks to built-in software, John Deere tractors, that iconic symbol of the working farm, don’t need a farmer in them anymore. Software, as the last scalable solution to many complex problems, holds great promise—as long as it works.

After my return, I was at a meeting with fifteen of the most skilled software developers I know. At one point in the discussions the developers were disagreeing about the definition of a unit test. Opinions of exactly what a unit test is ranged from a test of a unit of code, to tests of functionality. As I listened to the discussion I thought, if these people can’t agree on what a unit test is, how can other developers know what to do? As I got on my plane to return home to Boston from this meeting, I overheard the pilot telling the copilot to “just reboot it.”

One of the most rigorous approaches to building quality software is the software product line methodology (http://www.sei.cmu.edu/productlines/). Continental, an international automotive parts supplier, develops subsystems using this methodology. I recently bought a Volvo XC70, one of the first vehicles with Continental’s safety software.

I was particularly looking forward to being able to test the collision warning subsystem, part of the overall safety system. Potential hazards or obstacles are identified by the subsystem through cameras mounted on the front of the car. The cameras provide views at cross-traffic at intersections. I live in Boston, where in the wintertime mounds of snow often block visibility. I confidently pulled up to one such blind intersection. The cameras correctly displayed cross traffic … until a message was unexpectedly displayed, blocking out all video. The message stated, “Difficulty Connecting with Cell Phone … OK or Cancel.”

Sitting in the car and looking at the message blocking the screen, I was reminded of my friends’ question regarding my retirement, and my goal to improve software development. Even with as far as we have come and the advances such as the software product line methodology, I don’t think we are “done” yet with perfecting software, and that I have a long time before retirement.

However, adopting Scrum, becoming more agile and improving software development, costs money. It requires training, tooling, coaching. These are all investments. Scrum does not come with a set of tools for managing these investments, measuring the resultant benefits, and optimizing return on investment.

For the last several years, I’ve been developing a framework for managing this investment. It is called the Continuous Improvement Framework (CIF, yes, another acronym). CIF provides a set of management tools for continuously improving an organization and becoming more agile. Your agility is measured by metrics that reflect business value. The value of these metrics reflects your stage of agility. The framework shows you how to organize to increasingly use best practices. The result is a progressive movement from one stage of agility to the next.

CIF lays out modern, widely-accepted practices that, as adopted, progressively improve organizational return on software investment. These practices are grouped by management domain, with each domain accountable for progressive, measureable improvement. The progression of practices and the resultant improved metrics is the “signature” of each organizations progressive improvement.

CIF is under development, as I presented at Scrum Day Europe in Amsterdam in early July, 2012. Over the next six months, I will be working with several partners to validate, extend, test, and refine it. We will collaboratively increase its utility, flexibility, and value. I will post more about it here as Scrum.org  and our partners progress.

So, what does Scrum provide? It provides a labeled- environment within which complex development can be successfully managed (where the unknown is greater than the known). Scrum provides containers that allow teams to focus on one aspect of a complex problem  at a time. The containers are short-time boxes so that risk can be managed.

Scrum can be replaced or superseded by anything that also supports its underlying principles:

1. Self-organization – people doing complex work are much more effective organizing themselves and the work than someone who isn’t doing the work.
2. Bottom-up intelligence – figuring out how to do work is a management activity best performed by the people doing the work, since the work is unpredictable, with many twists and turns.
3. Empiricism – it is hard to plan what you don’t know, so we instead see what has been accomplished, and then figure out what to do next. We do this frequently to control risk and determine the best path to our goal.
4. Transparency – we periodically have to know what is actually happening to make effective empirical decisions.

As stated in bible of process control (“Process Dynamics, Modeling, and Control”, Ogunnaike and Ray, Oxford University Press, 1994) , there is no bad process. However, sometimes processes are applied to inappropriate situations. Scrum is an empirical process built on lean principles. It is most appropriate for optimizing complex work.

I welcome anyone who comes up with the next great process, one that does all of the above even better than Scrum. I’m still waiting.

“if you need to change an entire culture, here’s a tip: don’t be too idealistic about human nature.”

The article, in the Sunday 23 Boston Globe (http://goo.gl/jYLdY) posits that people don’t change because you appeal to their better side, or that you convincingly show them a more effective way of working or being. They respond because they believe that everyone else is doing it, and that they are out of step. The article says,

“What researchers have found is that … to really change how a group of people thinks and behaves, it turns out, you don’t need to change what’s inside of them, or appeal to their inner sense of virtue. You just have to convince them that everybody else is doing it.”

” There is something a bit circular about the idea that we change people’s behavior by tweaking their perceptions about the behavior of others. It’s a self-reinforcing process: the more people believe that smoking is atypical, for instance, the less typical it becomes, which in turn provides more evidence.”

We have the numbers:
1. 80% of all organizations say they are using agile techniques.
2. 82% of these organizations are using Scrum, among other agile techniques.
3. Most job posting for IT management and developers require a knowledge of agile techniques (we need some statistics on this).

Who would have thought this.

Best,
Ken

“I have a team that won’t self-organize.”
“ My team always selects more PBIs than they can do. The members say that the software is too complex and corrupt to finish anything.”
“My Product Owner isn’t engaged.”

What do I do??

In my Scrum classes, I ground everyone in the theory and first principles of Scrum. Why does it work? What is a complex problem? Why is short-cycle development necessary for controlling risk? What is transparency?

Then the members of the class work in teams. Case studies are given to them, starting with a context, and then the problem. The teams are asked what they would do. They work together, bringing their experience to bear, to come up with a solution.

The solution is a result of their projections of their experiences onto the problem that I gave them. Unfortunately, we are not in a live situation. They will not get to apply their problem and see if it works. They won’t be able to adjust the solution, bit by bit, empirically to continuously improve.

I am very wary of being an expert. I am even more wary of giving answers. “I have a question” require a detailed knowledge of the context, its history, and the problem. Then we can try something and see how well it works. If it is suboptimal, we can adjust it. As time marches on and it stops working, it can be adjusted again.

Forgive me for not giving quick answers. Surgeons don’t perform surgery over the phone, either (I think).

Some people on the Scrum Team learn by failing, trying again, and failing. Some are terrified of failing and need some prompting, some more coaching, some guidance. But they have to learn. Otherwise, they will always be dependent on the Scrum Master.

I pose the following question to Scrum Masters: “What is the best way to organize 100 developers into Scrum Teams and ensure that they select the correct Product Backlog items.”

The correct answer is to let the developers organize themselves into Scrum Teams. The Scrum Master may remind them that they have to have all the cross-functional skills on each Scrum Team to build a done increment. The Scrum Master may remind them that all 100 people must be engaged meaningfully and that mentoring is expected. The Scrum Master may have the lead developers lead a discussion about the software and architecture to be worked on, with the underlying dependencies. The Scrum Master may have the Product Owner discuss the intricacies of the Product Backlog. The Scrum Master may remind them that they have to deliver one integrated, integration tested increment at the end of the Sprint. But then it is up to the developers to organize themselves. I would expect that the lead developers would form the seed for the new Scrum Teams, but who knows?

If the Scrum Master organizes the Scrum Teams and parses out the Product Backlog, the developers are constrained by the intelligence and knowledge of the Scrum Master. If the developers organize themselves into Scrum Teams, we are engaging the intelligence of all 100 developers. And, if they organize suboptimally, they can correct and continually adjust team membership as they find out more. A learning organization. Bottom-up intelligence.

I have successfully used the technique of letting developers self-organize into teams with groups of up to 200 people. They were working on complex, mission critical software, included subcontractors, and didn’t necessarily know each other well. As training wheels, I once arbitrarily put them into Scrum Teams and then told them to fix my mistakes by reorganizing.

I’ve never tried more than 200 because I can’t get more than that in a reasonable sized room. I suspect that if I were able to do so, they would soon decompose themselves into smaller groups, then smaller groups, then Scrum Teams.

Imagine the arrogance of a Scrum Master who believes that he/she knows how developers should organize better than the people themselves. This Scrum Master often has the thought in his/her mind that to be sure, he/she must control the situation; after all, they think that they are in charge (they think).

Some food for thought.

I was considering waste in light of the notions of velocity and capacity. Some Scrum users try to predict the outcome of the upcoming Sprint using velocity, the amount of work or PBIs they predict can be done. One practice used to calculate this velocity is to inspect past velocities and study upcoming team capacity.

I wonder, though. When we start a project or a release, of course we have a general scope, a projected cost, and a probable date. We then move forward, Sprint by Sprint, adjusting our plans to the realities we encounter. We may go faster or slower than expected. We may encounter new opportunities or challenges. We may find that some of what we planned is of lower value than newly emerging requirements.

Let postulate that we ignore velocity and capacity entirely. At the Sprint Planning meeting, the Development Team selects some Product Backlog items and establish a goal. As the Sprint moves forward, they work with the Product Owner to remove PBIs that were more than they could do, or get more PBIs that fit within the goal if they have some time available. At the end of the Sprint, they have done what they have done. At the Sprint Review, the Product Owner, Development Team, and key stakeholders inspect and adapt based on what was completed.

We use short cycle development, with Sprints as short as a week, so that we will frequently know our progress toward our goals, commitments, and projections. I suspect, unless convinced otherwise, that any time we spend worrying about velocity or capacity is waste, not adding a whit of value.

Just thinking,

Ken

I’d like to change this phrase from Scrum But to Scrum And.  The new wording might be, “We use Scrum and we are continuously building, testing and deploying our increments every Sprint,” or “We use Scrum and we are collaborating and brainstorming within the Scrum Team to increase Value every Sprint.”

We are developing a Scrum-And framework  At the most basic level, the question is: Are you using Scrum or not (as defined in the Scrum Guide (www.scrum.org/guides). Scrum And is then a path of continuous improvement in software development beyond the basic use of Scrum. Equating the Scrum framework with the framework for chess, this is determining how good a product development organization you are just like determining how good of a chess player you are.

In Software in Thirty Days (Jeff and my new book), we map ways in which Scrum can be deployed. These are:

The Scrum And framework is mapped onto this deployment mapping as follows

 Starting with the Stacey graph, four threads of improvement beyond the framework are Scrum,Technology, People, and Business (domain). Organizations would probably improve in each thread at a different pace. Improvement in an organization’s skills in each thread would drive them from the basic Scrum usage to further stages. We expect that metrics such as productivity, quality, value, ROI, and total cost of ownership could be measured at each level.

Work is just beginning in Scrum.org and with its partners. When this is done, it should significantly supplement our Implementation Playbook. It should provide a guide for organizations that want to know how to start and how to improve their product and software development skills. This fits with Scrum.org’s mission, “Improving the profession of software development.”.

We will let you know when usable sets of this framework are available.

Ken