Here is a great interview with Jeff Sutherland by the BBC Academy (under 5 mins) See the original Article here
Jeff Sutherland, Co-founder of Scrum
Great book on Scrum and the history of Scrum (Amazon Link)
The latest Scrum Guide pdf download 2017-Scrum-Guide-US
Agile Manifesto
Manifesto for Agile Software Development – Agile was born out of Scrum (see https://agilemanifesto.org/)
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Twelve Principles of Agile Software
Principles behind the Agile Manifesto
We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity–the art of maximizing the amount
of work not done–is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
Henrik Kniberg –
A must watch if you have any interest in really understanding Scrum (under 16 mins – I watch in double time every time I want a refresh, so under 8 mins)
What are Scrum and Kanban anyway?
OK let’s try to summarize Scrum and Kanban in less than 100 words each.
Scrum in a nutshell
From Henrik Kniberg and Mattias Skarin – Great book Kanban and Scrum making the most of both
• Split your organization into small, cross-functional, self-organizing teams.
• Split your work into a list of small, concrete deliverables. Sort
the list by priority and estimate the relative effort of each item.
• Split time into short fixed-length iterations (usually 1 – 4 weeks),
with potentially shippable code demonstrated after each iteration.
• Optimize the release plan and update priorities in collaboration
with the customer, based on insights gained by inspecting the
release after each iteration.
• Optimize the process by having a retrospective after each
iteration.
So instead of a large group spending a long time building a big thing,
we have a small team spending a short time building a small thing. But
integrating regularly to see the whole.
121 words… close enough.
For more details check out “Scrum and XP from the Trenches”. The book
is a free read online. I know the author, he’s a nice guy :o)
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
Kanban in a nutshell
• Visualize the workflow
Split the work into pieces, write each item on a card and
put on the wall.
Use named columns to illustrate where each item is in
the workflow.
• Limit Work In Progress (WIP) – assign explicit limits to how
many items may be in progress at each workflow state.
• Measure the lead time (average time to complete one item,
sometimes called “cycle time”), optimize the process to make
lead time as small and predictable as possible.
Team of Teams
In this book, Gen. McChrystal states that reaction time in a traditional Command structure was somewhere in the region of 3 months to 6 months (or never), in the Command of Teams structure reaction time was 2 weeks but in the Teams of Teams structure reaction time was 20 minutes!
Great book that argues the case for creating a flat organization (Amazon Link)
