Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.
So now that we have set a little context, it's time to start
getting down to the business of talking about how to solve the problem.
About time huh? This next section is intended to bridge to a high-level
description of the solution and then a chapter by chapter breakdown of
how the book is going to flow. I'll try to get the rest of this out
either over the weekend or early next week.
and by the way, if you've given me formal feedback on any of this
content... and some of you have... that feedback has not made it into
any of these upcoming sections. We want to get through finishing the
narrative (the one I talked about last time) and then figure out how to
deal with the new content in a more holistic manner.
Agile Isn't Always Enough
is primarily a book to help managers like Frank. It is directed at the
mid-level manager that needs to develop an approach for adopting agile
within their part of a larger organization. These are people that want
practical guidance on what to do next and how to articulate why what
they decided is the next right move. Managers like Frank need a
framework to facilitate conversations about what to focus on first and
how to build their organizations within a larger organizational
context. They need to understand how their decisions impact their teams
and how their teams impact the larger enterprise value
This book is geared toward helping these
managers incrementally adopt agile and build out a scalable agile
enterprise. That said, agile methodologies are primarily intended to
work with small teams and not necessarily designed to scale. When it
comes to agile in larger enterprises, we find that much of what is
prescribed is incongruent with where most organizations find
The guidance is insufficient to drive
significant and meaningful transformation. The gap is just too large
and there is no path from here to there. There is a huge difference
between doing agile in a large company and a large company that has
fully embraced an agile way of doing business. Asking the business to
do less and ‘trust the team’ is insufficient guidance for large,
complex organizations. Telling large organizations not to be large and
complex is a non-starter. Suggesting a scrum-of-scrums as the lone
scaling mechanism does not give sufficient guidance to the manager
trying to convince a skeptical leadership team.
light framework that leaves out things that are sometimes useful can be
smart. One that leaves out things that are virtually always useful is
Allan Shalloway, NetObjectives
effectively build a sustainable agile enterprise, we will need to go
beyond some of our standard agile thinking and incorporate learning’s
from the methodologies that came before (waterfall and RUP) and those
that are coming after (Lean and Kanban). We will draw from luminaries
in the fields of manufacturing, team dynamics, organizational design,
change management, systems thinking, conversation theory, and
organizational learning. Along the way, we’ll need Goldratt’s Theory of
Constraints, Covey’s Seven Habits, and Kotter’s Leading Change amongst
I thought the Shalloway quote
was cool... it was something that he said over Twitter. Right now I
have no idea how to footnote something like that, so I am open to
suggestions. I did tell Alan that I was going to use it though ;-) Next
up... overview of the value driven agile transformation and then a
chapter-by-chapter discussion of the book's layout.
The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.