Scrum Development Blog

Better teams make better products.

Archive for the ‘Agile Pathways’ Category

Kanban Vs. Scrum

Agile Pathways | Posted by The 3Back Team
Feb 11 2010

Will Kanban replace Scrum?

Choose

  1. No way, they are opposites: Kanban is for flow / Scrum batchscrum flow kanban flow
  2. Yes, Scrum is old school big planning steps
  3. Yes, Kanban minimal planning / Scrum is heavy planning
  4. 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.

What You Should Know After CSM Workshop

Agile Pathways | Posted by The 3Back Team
Mar 11 2009

This is a great read and summarizes what should be learned in a CSM course. As you read remember this is something that you have to learn is true and the only way we have found to teach people this is for them to apply the scrum framework to their jobs.

Message from Ken at the Scrum Alliance

  • Scrum is a framework for iterative, incremental development using cross-functional, self-organizing teams. It is built on industry best practices, lean thinking, and empirical process control.
  • Scrum is optimized for high yield product management and product development. Scrum is particularly appropriate for high risk, complex, large projects and can be used when other parts of the endeavor are hardware or even waterfall development.
  • If waterfall suits current needs, continue using it.
  • An enterprise can use Scrum as a tool to become the best product development and management organization in its market. Scrum will highlight every deficiency and impediment that the enterprise has so the enterprise can fix them and change into such an organization.
  • Whenever an enterprise modifies or only partially implements Scrum, it is hiding or obscuring one or more dysfunctions that restrict its competence in product development and management.
  • The iterative, incremental nature of Scrum puts stress on the product development organization to improve its engineering skills and on the product management organization to optimize the return on investment of every release and project.  The phrase, “That can’t be done here” really means that it will be very difficult to do so. The gap between current practices and target practices is a measure of incompetence and competitive risk.
  • The use of Scrum to become an optimized product development and management organization is a change process that must be led from the top and requires change by everyone within the enterprise. Change is extremely difficult and fraught with conflict, and may take many years of sustained effort. Turnover of staff and management can be expected.
  • The most serious impediments to using Scrum are habits of waterfall, predictive thinking over the last twenty to thirty years; these have spawned command and control management, belief that demanding something will make it happen, and the willingness of development to cut quality to meet dates. These are inbred habits that we aren’t even aware of anymore.
  • The focus of using Scrum is the change from old habits to new ways of doing business. Scrum is not implemented or rolled-out as a process; it is used to foment change.
  • Scrum is not a methodology that needs enhancing. That is how we got in trouble in the first place, thinking that the problem was not having a perfect methodology. Effort centers on the changes in the enterprise that is needed.
  • Iterative, incremental development is much harder than waterfall development; everything that was hard in waterfall engineering practices now has to be done every iteration, and this is incredibly hard. It is not impossible, but has to be worked toward over time.
  • Managing a release or project to deliver only the highest value functionality and not deliver the rest optimizes value is the job of product management and customers.
  • Self-optimizing teams are extremely productive. When they work closely with the customer to derive the best solution to a need, they and the customer are even more productive.
  • A team consists of people under pressure to do their best. Conflict is natural and the team needs to know how to deal with the conflict and have resources to draw on when needed.
  • The role of an enterprises management changes from telling people what to do to leading and helping everyone do their best to achieve goals. People aren’t resources and managers aren’t bosses.

Well Formed Teams and the Agile Pathway

Agile Pathways, Well Formed Teams | Posted by The 3Back Team
Mar 03 2009

When people consider what got them to their current market or look closely at how their competitors are succeeding they see smart, sharp, fast hyper-productive teams. They find that some organizations possess a knack for rapidly configuring themselves into a shape and deploying their hyper-productive teams to rapidly build new product capabilities. Some competitive organizations can do this within days or a few months not years. By the time a competitive analysis is completed of what the competition is doing the market is already changing and moving on. What we see is a need for continuous analysis, consumption of that analysis and a rapid deployment of new capabilities.

After peering closely at what got them to their current position of success we see a “well formed team”. It is amazing how quickly people in corporate america can forget the power that was present from these teams and what they are able to produce. One thing is clear. A WFT was at the heart of their success and everytime they try to create that magic without a WFT ideas just don’t seem to flourish.

You Don’t Do the Agile Process You Are the Agile Process

Agile Pathways | Posted by The 3Back Team
Mar 03 2009

You Don’t Do the Agile Process You Are the Agile Process

Saying it this way puts and emphasis on starting with self and looking inward before blaming outward.

For an agile process to be successful, and probably any process at all, it must allow some focus on people, passions and teams working together.

  • Without an aim we have no purpose and not much of a reason to be a team. When we have that product aim we can test our ability to work together by looking at the results of our product development effort.
  • Without a focus on people we often on mechanics of the process to the exclusion that people matter.
  • And without working towards our passions we fail to ignite the energy within ourselves and we fail to contagiously spread our enthusiasm to others around us.

When we properly include the above three in our line of vision and don’t fall prey to using a model of software development that is so complex there is no room in our heads for the above three, we can win BIG time. What we focus on matters and if the process is so complex there is little room to think about anything else, then we loose.

A recurring pattern, that we have observed in large scale adoption of Agile “The Pursuit of Enterprise Agile” . Is a successful pilot that really focuses on the people working together, can ignite a ground swell approach to adopting agile.

Typically, organizations get started by contracting with outside an outside expert who advises them how to start agile. The advice is typically some setup a pilot that will be small enough to influence yet important enough to keep attention focused. The idea behind a pilot is simple, “Let’s setup a little experiment with this thing called agile and see how it works out for you?” After a business case review or senior leadership buy-in, the pilot is set up with an appropriate amount of autonomy.

Usually, an internal person is to be part of the pilot and run it. That person is charged with setting up the pilot and documenting their observations so that the organization can learn. A team is formed, trained and started down the agile path. The team works shoulder to shoulder with an on-site agile consultant who demonstrates the habits and values of agile while in motion. Often the team quickly emulates the behavior and then falls into a rhythm of product development and delivery.

Then someone “process experts” typically take the observations of the people working together and abstract them. Now things really get whacked. The process expert believes they can take observations of the pilot and fold lessons learned into the enterprise methodology view. This is a too “hard problem” we have been trying to do this for years and are still in our infancy for understanding basic communication. However, based on what is written and documented in classic process literature you would be lead to believe we have evolved far more than we have.

After organization have absorbed the lasted round of process learning into their enterprise methodology. The very real skills and valuable team behaviors that were gained are lost. The next agile effort looks very much like the old process the organization ran before just with new words and language. The part that made the pilot effective is lost.

That is why “You Don’t Do the Agile Process You Are the Agile Process” works so well as a phrase. It constantly reminds me that agile starts with self.

People, Passions and Teams must be elevated above Principles, Philosophies and Practices. Without the first three the last three will not matter.

Post-Agile and Pliant Software – The Emperor’s New Agile

Agile Pathways | Posted by The 3Back Team
Mar 03 2008

A colleague writes:

Over the past few weeks, I’ve been digging into links, blogs, forums using this term (Post-Agile)… Have you seen this term? Followed it’s discussions? Any comments?

…Pliant Software is another term that seems to be associating itself with Post-Agile…

I think the software world is sort of like a customer who has an idea of what they want or need, but can’t put it into words. But, and after several iterations of “Requirements Gathering”, has come out of the room with more terms and an RD that is better than it was at the start — but not perfect, yet!

(italics mine)

Yes, I have comments!

  1. I agree that the newness of agile has worn off, and the immediate benefits from it have been tapped dry by many.
  2. I’m annoyed at the PliantAlliance site’s claim for “a new way of thinking about developing software” — pliant sounds like adaptive to me, and Scrum has been saying this for a while.
  3. While the immediate benefits of agile have been tapped, the deeper benefits that can be realized by changing the way we collaboratively build product — not just the way developers write code — have a long way to go. Before we decide that “agile didn’t work,” I’d like to see more organizations actually practicing basic agile behaviour, and I’d like to see actual practices in use catch up to the huge body of literature describing deeper agile practices.

Good Software is a craft, like smithing or theatre. There was never a school that turned out expert blacksmiths; novices had to progress from apprentice to journeyman to master. The “Fame” school doesn’t promise its graduates fame, they have to go out and earn it through experience.

Good Software is the result of human thought — not just human labor — and is highly resistant to being made into a detailed process/algorithm, or body of knowledge.

Good Software is the result of collaboration. Social Science and more enlightened ways of interacting can help, but trying to describe them is missing the point.

I understand that post-Agilists see themselves as giving a name to an existing movement, rather than trying to create a new movement. But it smacks of picking a new name for your club because one member of your club is acting silly, and people are now making fun of you: you fragment the group, you tacitly approve of the bad behavior by distancing yourself from it rather than correcting it, and you spend too much time and energy on labels rather than action.

My friend’s point is right on: the SD world is like a user with a poor Requirements Doc, who “knows what they want, they just can’t describe it yet.” Trying to describe it, trying to codify it, is ulitimately a losing game and a waste of time — just like writing big RDs is a waste of time.

Build successful, adaptive teams who can make good, useful software, point to them and say “THAT is what Agile is.”

Agile Is Going Mainstream But They Still Don’t Get It

Agile Pathways | Posted by The 3Back Team
Mar 03 2008

Agile is gaining mainstream acceptance. In a recent poll run by business week they ranked agile software development as item #33 (read here) in things that are shaping the business world.

This is great and seeing agile gain acceptance at this level as well as publications from mainstream places like Business Week and CNN is a huge step forward.

Why they don’t seem to “get it
Many of the remaining trends are focused on individuals and not teams. This continues to be counter to the agile movement where brilliance is really a team commodity and that corporations are still looking for the individual to lead them to greatness. Our need for education remains strong in the area of teaching people to join teams and leverage the emergent qualities of social brilliance. In other words have a conversation that establisher a trusted report so that we get smart together.