John Hines' Software Process Blog

A blog on Agile software development and Scrum

  Home  |   Contact  |   Syndication    |   Login
  39 Posts | 6 Stories | 42 Comments | 0 Trackbacks

News

The information in this weblog is provided “AS IS” with no warranties, and confers no rights.

This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.

To err is human, to forgive is divine.

Tag Cloud


Archives

Post Categories

agile

Working in an enterprise environment is a unique challenge.  There's a lot more to software development than developing software.  A project lead or Scrum Master has to manage personalities and intra-team politics, has to manage accomplishing the task at hand while creating the opportunities and a reputation for handling desirable future work, has to create a competent, happy team that actually delivers while being careful not to burn bridges or hurt feelings outside the team.  Which makes me feel surprised to read advice like:

" The enterprise should figure out what is likely to work best for itself and try to use it."
- Ken Schwaber, The Enterprise and Scrum.

Most large enterprises are fundamentally unable to be self-reflective.  It's like asking a Roman gladiator if he'd like to carve out a little space in the arena for some silent meditation.  It is an open question as to how compatible Scrum is with the top-down hierarchy of life in a large organization.  Specifically, manufacturing-mindset, fixed-release, harmony-valuing large organizations.  It's become clear why Agile can be a better fit for smaller companies without much organizational inertia.

A developer, team, organization, or enterprise can be Agile without using Scrum.  But it isn't obvious what process would be the best fit, in general, for an enterprise that wants to become Agile.  It's possible one should read more than just the introduction to Ken's book.

I do feel prepared to answer some of the questions asked in a previous post:

  • How can Agile practices (including but not limited to Scrum) be adopted in situations where the highest-placed managers in a company demand software within extremely aggressive deadlines?

    Answer: In a very limited capacity at the individual level.  The situation here is that the senior management of this company values any software release more than it values developer well-being, end-user experience, or software quality.  Only if the developing organization is given an immediate refactoring opportunity does this sort of development make sense to a person who values sustainable software.
     
  • How can Agile practices be adopted by teams that do not perform a continuous cycle of new development, such as those whose sole purpose is to reproduce and debug customer issues?

    Answer: It depends.  Scrum is not well suited for unpredictable work.  While you can easily adopt XP practices for bug fixing, the project-management aspects of Scrum require some predictability.  The question here was meant for those who want to apply Scrum to non-development teams.  In some cases it works, in others it does not.


  • How can a team measure if its development efforts are both Agile and employ sound engineering practices?

    Answer: These should be measured independently.  The Agile Principles are a terrific way to measure if a software team is Agile.  Sound engineering practices are those practices which help developers meet the Agile Principles.  Scrum can be mistakenly applied as an engineering practice when it is essentially a project management practice.  In comparison, XP and Lean are examples of sound software engineering practices.


  • How can Agile be explained in an accurate way that describes its benefits to sceptical developers and/or revenue-focused non-developers?

    Answer: Agile techniques will result in higher-quality, lower-cost software development.  This comes primarily from finding defects earlier in the development cycle.  If there are individual developers who do not want to collaborate, write unit tests, or refactor, then these are simply developers who are either working in an area where adding these techniques will not add value (i.e. they are an expert) or they are a developer who is satisfied with the status quo.  In the first case they should be left alone.  In the second case, the results of Agile should be demonstrated by other developers who are willing to receive recognition for their efforts.

It all comes down to individuals, doesn't it?  If you're working in an organization whose Agile adoption consists exclusively of Scrum, consider ways to form individual Agile teams to demonstrate its benefits.  These can be virtual teams that span people across org-chart boundaries.  Once you can measure real value, whether it's Scrum, Lean, or something else, people will follow.  Even the curmudgeons.

Technorati tags: Agile Scrum

posted on Wednesday, February 9, 2011 12:10 AM