Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.
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.
Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.