"Deliver frequent, tangible, working results"
Peter Coad


"Kanban is the science of not trying to do too much at once"
Stephen Palmer, 2012


"We try to solve the problem by rushing through the design process so that enough time is left at the end of the project to uncover the errors that were made because we rushed through the design process"
Glenford Myers (via jJeff De Luca)


"I guess that as you go along you try to fill your tool-box, so that when you face these circumstances you have more options to choose from"
Jonny Wilkinson, Tom Fordyce's Blog, 2009


"The structure of a software system will reflect the communication structure of the team that built it."
R. E. Fairley


"Man will occasionally stumble over the truth, but most times he will pick himself up and carry on."
Winston Churchill


"If you can't explain it simply, you don't understand it well enough."
Albert Einstein


"Use models to find out how things work or to find solutions to puzzling dilemmas. Create models to communicate ideas and understand things you can’t see. Recognize models and the countless ways models are used for working, playing, teaching and explaining. Assess models for what they do and don't tell you about the real thing and how useful they are"
Boston Science Museum


"Human brain capacity is more or less fixed, but software complexity grows at least as fast as the square of the size of the program."
Gerald M. Weinberg, Quality Software Management: Volume 1 Systems Thinking, 1992


"The complexity of software is an essential property, not an accidental one. ... Many of the classical problems of developing software products derive from this essential complexity and its nonlinear increases with size."
Frederick P. Brooks, The Mythical Man-Month, 1995


"As the number of people increases, the ways they can interact tend to multiply faster than you can control them."
Gerald M. Weinberg, Quality Software Management: Volume 1 Systems Thinking, 1992


"chaos often results when a project's complexity is greater than its managers' ability to direct meaningful progress toward a goal."
Ken Schwaber, Agile Project Management with Scrum, 2004


"When people are factored in, nothing is simple. The complexity of individuals and individuals working in teams raises the noise level for all projects."
Ken Schwaber, Mike Beedle, Agile Software Development with Scrum, 2002


"It usually takes more than three weeks to prepare a good impromptu speech."
Mark Twain


"Simplicity is the final achievement. After one has played a vast quantity of notes and more notes, it is simplicity that emerges as the crowning reward of art."
Frederic Chopin


"We apply the analytic procedure in order to create a conceptual framework within which we can draw conclusions about the means by which a system solves its tasks. Indeed, we do this with the express purpose of establishing a solid foundation from which we can carry out a subsequent synthesis. This synthesis, in turn, acts to verify the conceptual model as an explanation. The process is an iterative one."
Tom Ritchey, Refactoring, 1991,


"Speech is conveniently located midway between thought and action, where it often substitutes for both."
John Andrew Holmes


"Information Technology is 80% psychology and 20% technology "
Jeff De Luca, www.nebulon.com


"Perhaps the worst software technology of all time was the use of physical lines of code [for metrics]. Continued use of this approach, in the author’s opinion, should be considered professional malpractice."
Capers Jones, Applied Software Measurement


"Agile software development is about iteration not oscillation"
Jim Highsmith (paraphrased), Agile 2009


Notes on Ken Schwaber and Jeff Sutherland's rugby inspired Scrum approach to managing agile software development (among other things).

Scrum is one of the self-styled agile approaches to software development that emerged around the turn of the century. Today it is arguably the most popular of these processes due to its elegant simplicity and ease of adoption.

Invented by Jeff Sutherland and Ken Schwaber, Scrum splits a project into a number of fixed length time boxes or iterations called sprints. At the beginning of each sprint the project team meets to select a subset of items from a priortised to-do list known as the product backlog. The subset of items chosen from the product backlog are the items that provide the most business value for the customer and which the team believe they can complete by the end of the sprint. This selection process is known as Sprint Planning.

The team work uninterrupted for the whole sprint on the items they have selected. In the meantime, a person assigned the role of Product Owner for the project works with the customer to modify, refine, add to, and adjust the relative priorities of the items left on the product backlog. The aim of the Product Owner is to ensure the items of highest current business value are always at the top of the backlog, and are ready to be selected and worked on during the next sprint. In addition, the Product Owner is available to the team throughout the sprint to answer questions about the items being worked on during that sprint.

At the end of a sprint the team hold a Sprint Review meeting where they demonstrate the completed work to the Product Owner and other interested parties. Any incomplete items, or rejected items go back on the Product Backlog with relative priorities adjusted as necessary.

The process then repeats until the Product Backlog contains no more items worth developing.

Scrum derives its name from a very short, disciplined, stand-up meeting called a Scrum meeting, held every day by the project team during a sprint. Each member of the development team lists what they have done since the last Scrum meeting, what they will be working until the next Scrum meeting, and anything blocking their progress. No discussion is allowed during the Scrum meeting. All necessary follow-up discussion is held between interested parties afterwards, enabling other team members to continue working.

Scrum defines only one other meeting, a short retrospective held within the team after each Sprint Review meeting to discuss and decide on possible improvements to the way they are working during sprints.

In addition to the role of Product Owner who is ultimately responsible for the contents of the Product Backlog and Development Team member, Scrum defines only one other role, that of Scrum Master. The Scrum Master is a somewhat deceptively named, facilitation and coaching role that enables and enforces the Scrum process.

Scrum is deliberately silent on all technical and engineering aspects of the project. It requires the Development Team to organise itself to do whatever is necessary to meet its commitment to deliver the items chosen to be developed during each sprint.

There is no doubt that Scrum has proven that small teams of dedicated, skilled developers that work well together can produce high-quality software that does what is asked for.

To be honest, most people in the industry including most managers already knew that. What those managers may not have known is whether they had teams of dedicated, skilled developers that worked well together, and whether or not what those teams were being asked to produce was what was actually needed.

Scrum strips away much of the baggage of older, more formal processes and makes how development teams work much more visible. It does the same for those that supply the requirements for the software; the product owners and their sources. There are no large documents or complicated repositories of detailed business and technical requirements or designs subject to interpretation, ambiguity and omissions to hide behind. Scrum is the teeny-weeny polka-dot bikini of software development processes, leaving little left to the imagination, and inescapably revealing the state of the project to all who wish to see it.

Strengths

Compared to other processes, Scrum is:

  • Easy to adopt
  • Simple
  • Enjoyable
  • Provides good visibility of project status

Weaknesses

To be successful, Scrum requires a very able and strong Product Owner or a Product Owner with good problem domain knowledge supported by a very able and strong Scrum Master.

It also requires able, experienced, and disciplined development team members because it provides:

  • No guidance on technical or engineering best practice especially with respect to architecture: problem domain, technical, or physical.
  • No guidance on verification best practice such as automated testing and peer review.
  • No guidance on technical documentation best practice such as design, operations, and end user guides.

Coordination between multiple Scrum teams on such things as overall, shared architecture and integration work, is a challenge. While a number of solutions have been proposed, none of them are officially part of the definition of Scrum.

There is a vast difference between a product that forces you to change the way you work and one that inspires you to work differently. Being forced to do it 'their' way is uncomfortable and usually unproductive. The freedom to discover better ways of working is more enjoyable and inspires new insights into other approaches to get your work done.
Andy Carmichael, Better Software Faster, 2002

Managing Bug Fixing in Scrum

Eventually everyone who has done some basic Scrum training asks the question, "How do you handle the fixing of bugs? Where does this fit in the process?"
Read more...

Story Points from Incomplete Stories

Another common question that teams new to Scrum ask is what should they do with the story points of an incomplete User Story at the end of a Sprint?. Should the team be 'credited' with those points or not?
Read more...


Feature-Driven Development

FDD combines key advantages of other agile approaches with model-centric techniques and fluid team organisation. This means that FDD easily scales to much larger teams and projects than generally recommended for other agile approaches. FDD is also characterised by an emphasis on quality throughout the process, and timely, accurate, meaningful status reporting and progress tracking for all levels of leadership.
Read more...

Domain-Driven Design

Domain-Driven Design comes as a bit of a surprise to those who have been taught that agile software development and especially eXtreme Programming do away with the need for analysis and design techniques like object modeling and notations like the Unified Modeling Language (UML). It is actually very obvious that any software team working in a .Net language, Java, Objective-C, C++ or any of the object-oriented dynamic languages such as Python or Ruby has an object model at the heart of their software.
Read more...

eXtreme Programming

The premise behind eXtreme Programming is that the cost of making changes to software does not need to grow exponentially more expensive throughout a project or product development life-cycle. That the cost of change does increase exponentially over-time is attributed to unnecessary complexity added early in the project product life-cycle; complexity that provides the flexibility to address all the changes that might be asked for in the future.
Read more...

Follow me on Twitter...