Feed aggregator

### #ScalingScrum: How Do You Manage a Backlog Across Multiple Teams?

Scrum Log Jeff Sutherland - Wed, 03/26/2014 - 17:49
Scrum is being used for everything from massive software implementations, to cars, to rocket ships to industrial machinery. Scrum Inc.'s Chief Product Owner, Alex Brown, is in the midst of putting together a presentation on a modular way to scale scrum.

He has noticed that when projects scale-up, one of the first issues organizations must confront is how to manage a Product Backlog across multiple teams.

Some organizations work from one master backlog managed by a Chief Product Owner or a Product Owner Team. Multiple teams then pull stories from that backlog.

Other organizations have teams with individual product owners who create their own backlogs and release their own modules into a loosely coupled framework. Spotify has set up their entire organization to enable this. (They also carefully manage dependencies across teams.)

There is a whole spectrum of options between these two examples. The right answer for any company lies in their own context. If you're building something where all the modules are intimately integrated, a single, tightly managed, master backlog may work well. In a different environment, it might be faster for individual teams to continuously release improvements on their own module. There is coordination on the epic level, but Sprint-to-Sprint, their backlogs are independent from each other.

These models work for different Scrum implementations and we know there are even more ways of doing it. We would love to hear your story so we are extending an open invitation to the Agile community:

How do you manage your backlog across teams?

We want to learn how your context shapes your practice. Why do you do it that way? What kind of product are you building? How many teams do you have? And how is your method working for you?

As the conversation winds down, we'll write a blog and compile the most interesting and effective techniques so we can learn from each other.

In the coming months, look forward to a Scrum Inc. online course in which Alex and Jeff present a framework for scaling Scrum. They will also share this framework at Agile 2014 in Orlando.

--Joel Riddle

Categories: Blogs

### More Effective Handoffs, Less Chaos with LeanKit

For many teams, relying on emails and verbal communications to manage work handoffs alone results in misunderstandings and oversights.  If this sounds familiar to you, see how CoreCommerce has streamlined the way they work using LeanKit to visualize what needs to get done. We had the opportunity to chat with Matt DeLong, CEO of ecommerce […]

The post More Effective Handoffs, Less Chaos with LeanKit appeared first on Blog | LeanKit.

Categories: Companies

### Nice Summary of Personal Kanban

Wired magazine has a nice little summary of personal kanban.  Check it out!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just \$500 for a team to get targeted advice and great how-to informationPlease share!
Categories: Blogs

### Why Take A 3-Day Certified Scrum Master (CSM) Class?

Danube - Wed, 03/26/2014 - 05:48

The Certified Scrum Master (CSM) class I’ve usually offered is an interactive cartoon e-learning series (Scrum Training Series completed before attendance) + two days of team lab activities.  It gets great reviews, such as this one from my last class:

Attended a Scrum Master class with Michael James as the teacher, and it was amazing. He was extremely knowledgeable, professional, and fun to get along with. I’d highly recommend anyone to take one or more of his classes.

While I was writing this article, a participant from the Washington DC area posted this on my LinkedIn profile:

I left the class so well-prepared for the certification exam — and so much more. I felt ready for the real world, as Michael, after ensuring that we were ready for the exam, maximized our practical learning through hands-on team activities, plus explanations of key Scrum and Agile concepts illustrated from his own professional experiences. I cannot imagine a better learning experience.

But many participants wish we had additional time to dig deeper into the implications of Agile to organizations that have more than seven people.  Large organizations are where Scrum gets screwed up the most.  The principles are exactly the same, but the layers of self deception and muscle memory in big companies stump even expert consultants.

So we’ve decided to offer a 3-day CSM class.  (It’s actually 3.1 days if you count the cartoons and quizzes everyone does before the class.)  Most of the additional time will focus on examples and case studies.  As always, we’ll use fun interactive techniques that aid retention.  I use activities rather than long lectures because we’ve found people don’t remember lectures that go on longer than 5-10 minutes.  Years ago when I switched to activity-based learning, a university professor who attended my class in Europe wrote:

a fluid uninterrupted learning experience…. interesting, high value training.

The 3-day CSM class will appeal to you if:

• You are the type of person that has a natural curiosity for learning
• You push yourself to be the best in whatever you do
• You enjoy problem solving and are comfortable with ambiguity as you explore the best options for a complex situation
• You appreciate theory but learn best by doing
• You are a job seeker wanting to be more knowledgeable about Agile during job interviews than an ordinary CSM
• You are a consultant who wants greater confidence in guiding organizations
• You are a business leader seeking to avoid common mistakes in implementing Scrum

The main topics covered by primarily by team activities and examples:

• How Agile development differs from traditional project management.
• Three Scrum roles, responsibilities, boundaries, in depth.
• How to write well formed Product Backlog Items such as user stories.
• Techniques for splitting large requirements (e.g. epics) into small specific ones.
• Product Backlog prioritization.
• Effort estimation.
• Maintaining the Sprint Backlog.
• Five Scrum meetings (how to, how not to).
• Sprint execution for self organizing teams.
• Definition of done and the potentially-shippable product increment.
• Environments that encourage or impede team self organization.
• Small group dynamics (the psychology of innovative teams).
• Modern Agile engineering practices including test-driven development (TDD).
• Lean principles derived from the Toyota Production System.
• Product Owner planning and forecasting beyond one Sprint.
• Case studies of Scrum in large organizations.
• Case studies of Scrum for large scale development.
• Case studies of common organizational impediments.
• Case studies of successful and unsuccessful attempts to introduce Scrum/Agile to organizations.

The class contains individual and group knowledge tests that precede the ScrumAlliance’s online test.

Better prepared groups are able to spend more time on the advanced topics.  For this reason, I will need you and your colleagues to complete the Scrum Training Series before class, and work with me beforehand about any areas of confusion.  During the class you’ll be on a fast moving team applying what you learned before the class.  The Scrum Training Series is also highly regarded:

This series is FANTASTIC! It was entertaining, engaging and informative. I’m very new to SCRUM and this material was presented in a very logical, easy to understand manner. It’s such a logical framework and approach! In fact, I sent the link to all the PMs in my company (we’re implementing this approach to SDLC).

We’re initially offering the 3-day CSM class in Seattle (April 28-30), New York (May 7-9), and San Francisco (June 10-12). Participants have already started signing up.

The post Why Take A 3-Day Certified Scrum Master (CSM) Class? appeared first on blogs.collab.net.

Categories: Companies

### My Favorite Coaching Technique

Illustrated Agile - Len Lagestee - Wed, 03/26/2014 - 04:22

It has been a few weeks since my last post but the good news is I have been spending this time putting the finishing touches on a book. I plan on getting it off to the copyeditor by the end of the week and will let you know a release date shortly thereafter.

In the meantime, I wanted to share a simple and low effort coaching technique I have been experimenting with. It’s my favorite for now but I’m sure something new will replace it.

As an enterprise agility coach, we are often bouncing from team to team or from problem to problem. So much so that we may be missing opportunities to strengthen our impact and make deeper connections with the people we are coaching. I found myself in this place of months ago so I decided to try something simple.

Around lunchtime and as frequently as possible, I would plant myself at a table in the break room. I am currently working at an organization with small lunchrooms on every floor so I would find the closest one, sit down and just wait. I would catch up on emails or get a little work done but I make sure to not act overly busy or have a “don’t bother me” look.

Initially, when people from the teams I was working with walked in they would just say hello or we would share pleasantries. Before long, they would stop and chat a little more about “agile” things. And after a while longer they would start opening up about their experiences on the team and within the organization.

Over the past couple weeks I have noticed a few side effects to setting up informal “office hours” during the middle of the day:

A building of trust. Being in an informal setting seemed to lower defenses and there is an easier time to connect on a personal level. When this connection is developed, advocates emerge. These advocates help to remove resistance.

Hearing what people really think. Being in an informal setting seemed to allow people to open up a little more. They started getting more comfortable sharing the pain points they have been experiencing and were perhaps reticent to share in a group setting.

A chance to elaborate teachings. Many teams are learning how to be more agile on the fly (see the post “Working on a Beating Heart”). It may be tough to provide additional details on “the whys” while in working sessions. During some of these lunch breaks people would just ask questions and we would discuss how to make something work for them.

An opportunity to learn and improve. I started learning about ways to improve my coaching and how people were receiving my teaching style . I heard this before but I was recently reminded that I start talking faster when I get excited about something. I still need to work on this!

Something simple to try. I would also recommend this technique for any leaders out there. Please share your coaching tips and experiences in the comments below.

The post My Favorite Coaching Technique appeared first on Illustrated Agile.

Categories: Blogs

### Interview with Al Shalloway of Net Objectives

Scrumology.com - Kane Mar - Tue, 03/25/2014 - 22:01

Alan Shalloway is a prolific author and founder and CEO of Net Objectives. I first met Al while living and working in Seattle, and would frequently see him at different conferences and gatherings.

Since this interview was recorded, there has been an interesting debate of the Scaled Agile Framework (SAFe). In order to better understand the SAFe framework, well known and respect Scrum Trainer Ron Jeffries attended a SAFe training course. Ron Jeffries wrote about his experience in this blog post. Although Ron has his reservations with SAFe, his respect for Alan is quite clear:

His Agile values and approaches are quite good. That meant that his sections of the lectures, and his answers about what he’d do in real cases, shifted the balance from what I believe we’d have gotten from the other instructor alone.

Al responded with a well reasoned and thoughtful reply.

… I do not agree the best way to achieve scale is always by getting the teams working well. As with most things, an approach depends upon the situation you are in. If the types of projects you are working on don’t require teams of more than 30-50 folks, I’d probably take Ron’s approach, because SAFe is likely too big for them. But many projects are too big or complex to unwind. In this case, looking at the big picture and getting teams to deliver in 2-week cycles may be the right approach.

I would encourage you to read both articles articles in their entirety. Alan’s latest blog post can be found here, and you can connect with Al on Twitter at @alshalloway.

This is a short interview, because I goofed and stopped recording after about 30 minutes. Even though the recording ends abruptly, I thought the start of the interview very interesting and worth sharing. Here it is:

Transcript [music]

Interviewer: Let me, very briefly give your background about what I was
trying to do. Maybe a couple of years ago, I felt like I was losing touch
with the people in the Scrum community. My wife and I, we moved out here to
Australia about four years ago. And Australia is a long way from anywhere.
And I felt like, I was starting to lose touch with people, and there were
new people coming into the community that have not met and were people that
I had not seen for a long time, such as yourself. And so, what I wanted to
do was, I wanted to find an excuse to reach out and talk to people.

Al: And that is cool.

Interviewer: Yeah, and I am of these people that needs an excuse to do
things. So the excuse that I created for myself was, that I would do
interviews and I would do interviews to ask people, about how they came
into the Scrum community. Just to chat about, where they came from.

Al: Okay, and in my case may be, how I got out of the Scrum community. I
guess am still in it, just not in the Scrum Alliance community.

Interviewer: Yeah if you are willing to talk about it. Personally, I
would be really interested to hear about that story. I do not know the full
details, I know some of it, but I would love to hear about the full
details.

Al: I got in really early and if you are recording now that is fine, I am
cool if you are.

Interviewer: Yup, yup.

Al: That is fine, yeah. So I got in really early, I do not remember
exactly when. But I was doing Agile, well I knew that is what I was doing
because I think I was doing it beforehand, and did not even know that is
what it was called. But as early as 99, when I heard Martin Fowler talk
about extreme programming. I thought “Wow, this is cool stuff.” And by 2000-
2001, we were doing Scrum. I do not know when Ken’s book came out, but
whatever year it came out, I read it. I was at all the early Scrum
gatherings. Actually, we sponsored one of the early ones when. Like I
remember one of the gatherings we went to, there were like 50 people, that
might have been the first one. And the first two or three or four years, I
was really avid about Scrum because at that time, there was no good way to
explain, why doing things in this steps make any sense. I mean intuitively,
I had been doing it for a while. But from a business point of view, it was
difficult to explain. And Ken was really good at explaining.. And I thought
wow, this is really cool. This adjusting and responding and building small
pieces, and this discipline. Agile and Scrum were at that point, not quite
synonymous, but iterations.

I remember, I would describe Agile as iterative, incremental and
integrated. That if you are doing those three things, that was the essence
of it. And Agile and iterations, these were sprints, to use the Scrum
terms, they were connected. The thought of what Kanban and flow is now,
that just never occurred to me or anybody else I think. So I was actually
really into the Scrum community. We had a lot of CST’s, like other people
did. I never became a CST because basically, I was doing other things, and
I was the CEO of Net objectives, still am. And being a CST seemed to be,
not where I should be focusing because then, there was a very limited
number of CST’s in those days, it was very difficult to become a CST in

And basically, but I had a couple. We did a lot of Scrum training. I
did other kinds of Agile training. And this went on for about three or four
years until 2004-2005, when two things started bothering me. One was, we
kept running into organizations where Scrum would not work, and it would
not work for any number of reasons. And one of the reasons was, if it was
big, there was no way to create a common vision to get people to work
together. And as Scrum as Scrum, we never could figure out how to get that
to work. In fact, we never did, we did other things right from the very
beginning. I go back to my early writings, and we talked about, I cannot
remember what we called it, but it was some group, that now is actually
kind of, you could think of it as a separate group of product owners,
talking to each other. But I forget what we called it back then. But it was
the early stages of some, high-level contextual view of, how to manage
multiple teams of multiple projects, working together.

So one thing was, this lack of vision, to create, for people to come
together. And the other problem was, there were times when Scrum as a team
method framework, would not work. Iterations were just not the right
approach. Having cross functional teams, were not the right approach. And
all I would ever hear was, “No Scrum will always work, you just have to
follow it.” And I am like, “Well, that does not make any sense. There are
times you do not want to follow it. There are times when you have key
people and you cannot get somebody with the experience you need, on every
team. Then what you do?” And nobody was listening to me. It was very
frustrating. And what started happening is, I started bringing the notion
of Lean in because I started seeing that Lean could create the bigger
vision. I did not know how to solve this problem with key men or key women
or whatever. But there were some things about Lean that seemed very
appealing. And I started talking about it in the community, and it was
really bizarre because, when I was talking about it in the community, I
would get a positive response. But I would be with Scrum folks, but if I
were talking about it openly, I was slapped on the wrist all the time. And
eventually that led to me being thrown off the Scrum development group
because it could not slow me down because Ken did not like me talking about
it.

So that was a piece of it. The other piece of it is, I really still
do not like the way the SCRUM certifies trainers, because what happens is,
companies make investments, get a CST and then the CST leaves. I thought,
The moment he came up with a CST program I said, “This is not a good model
because, it serves the individual, it does not serve the organization.” And
then every year you would see people getting CST and then leaving the
company, setting up their own shingle. And I just personally did not like
it, even though everybody was making a lot of money out of it, it did not
seem right. So those two factors really had me decide, “Well, I got my
hands tied when I am in this community, so I am going to go elsewhere.” It
did not change my opinion to Scrum. I think Scrum is a really good
framework, for teams to work in. We do a lot of Scrum. We teach Scrum all
the time. We do safe silver partners, and it’s based on Scrum. But I do not
like the way it was being organized to expand, and that is basically why I
left.

Now I admittedly, I might have left in a calmer way or, might not
have did something, I am maturing. But that was my main thing you know, it
was not Scrum itself. So, I also got to say, I really like what Ken did
was, Scrum.org. We had been talking for years, that you needed to do team
training and not certified Scrum Master training and when he started doing
that I said, “Good for you, that is what you should have been doing for
years.” I had been talking about that as well to no avail. So I think there
were certain resurgence of technical practices into Scrum and it is a team
training now, instead of a Scrum Master training, is really important.
Because if you think about it, if you have only got two days to do
training, if you spend any time on how does a Scrum Master be, that is time
less, for, how does the team be. So, if you want to be, if you want to do a
three-day training, that explains all the Scrum Master role and all the
team role, that is cool. But most people do not have that kind of money or
time. So I think, Scrum.org actually is moving in the right direction, with
how they are going. They are also going through the rep approach, where you
have materials and people get sort of being able to do that. So, I guess
Ken’s learned some of his lessons, because I am not interested in working
with Scrum.org, but I have got to say, but I like the model. It is a whole
lot better, than what I saw, when I was with the Scrum Alliance, and then
broke off.

Now the other thing we have done and it is funny because I have been
accused of liking one thing or promoting one thing. And what is ridiculous
about that, is I am the only guy who does everything. I mean think about
it. I do Scrum, I do Kanban, I do XP. I used to be an accredited LKU
instructor with the Kanban method. I still do the Kanban method. It is just
one tool I have in my toolbox. I’m the only guy carrying around six tools,
when everybody else’s got two or three. And they think they have a variety.
So my thinking actually, the big umbrella for me is Lean. Lean is kind of
mindset and a framework. And it is based on just a few key principles that,
I guess the essence of Lean for me goes back or the foundation, not the
essence. There is a difference, on what it is built on, goes back to
something that I have been doing for, 30 years and that is Deming [sp].

Look to systems, trust that people are basically good, and if you put
them in a good environment, they will do good work. If you put them in a
bad environment, you will suppress them and they will not get good work
done. And that, you do not need to, try to cajole [sp] them to do good
because they naturally want to do good. But you have got to remove what is
in their way. And that takes improving the system, but it also takes good
management. It is not something that people by themselves can do because in
a big organization, there are lot of impediments that the individuals
cannot do. But create the right environment, then let them do well, self
organize within that environment. And then Lean, builds on that foundation,
by adding the notion of, do not stop the workflow. When you start work,
keep it going until it is delivered. Well the only way you can do that is,
if you have got small batches. So, Lean talks about just in times, small
batches. It actually talks a lot about testing, which most people I do not
think, realize. Because most of the books that I read about Lean, do not

But if you go back to [inaudible 00:10:51] book, the production
automation with a human touch. And of course, manufacturing is a lot
different from software, so do not try to do this in software, what they do
in manufacturing. But take the essence of it. The essence of it is, things
should run well, and when they do not, then you stop and figure out what it
is, get it to run well again and then you continue to skim through the
system, once something goes wrong. But you should not be testing things in,
and you should not be having to manage the process, it should flow
smoothly, as you do things. Excuse me, just allergies.

Interviewer: It is all good.

Al: So, the more I study Lean and the more I talk to different people,
outside of the core Lean community, a lot of things fit into it. Like Bob
Charette actually, I did not know this, but he actually was the one who
coined the term Lean software development. He wrote a paper, I think it was
in the 90′s.

Interviewer: Oh, really?

Al: Yeah, Mary and Tom did not coin the term, even though they are the
ones who get all the credit for it. Charette wrote, and I do not remember
what year it was, it could have been, as early as 89, but it was definitely
no later than ’99. I think it was a late 80′s. He wrote an article called
Lean software development, and I did not know who Bob was, until about five
years ago, at the first Lean Kanban conference. He was there, not was the
second one, it was the whatever was after Miami. It was that one and he was
there. And he told me this, and I was talking to him. He is a risk viewer,
this guy is just amazingly smart. Probably, the number one risk guy in the
notion together. And if you start studying, if you start taking the
principles, the foundation I should say, these principles from Lean and
Deming and apply them to software, then the practice will show up
differently. But basically, the ideas work on a small value pieces, as you
can, and make sense from a deployment point of view. And do not work on too
many things, so you have to stop work.

I love David Anderson’s phrase, “Stop starting and start finishing.”
I actually came up with myself just the other day. It just hit me,
finishing, it is “Stop stopping.” Do you know what I mean? You are working
and then like, you stop. And you stop because you need somebody else or
just because you do not know something or you stop because the bug happens
and the testers are not there or whatever it is. You have a stoppage in the
workflow and that is bad. So it is like, stop stopping, how do you set it
up so you do not have to stop, so you do not have to keep stopping. And
these mantras really guide you, no matter where you are. Then Scrum, if you
view it as part of the Lean world, becomes a lot better because you can see
how to extend it. And I am happy to say that the Scrum community is finally
acknowledging it’s a manifestation of Lean. I have to admit, I still get a
little irritated, I get less and less as time goes on because I am maturing
a little bit. But I get a little less irritated every year that, back six
years ago, when I was saying this, I was told, “No it is not. No, it has
nothing to do with Lean and all that.” But it is at least good now that it
is being said that it is Lean. It is a partial implementation of Lean
thinking and it is quite good. And when you actually acknowledge that and
see that, then when it does not quite work, you can use Lean thinking to
get you to the next level. That is why, I am not trying to say Scrum is a
part of Lean or kind of Lean, so you will do Lean. I think, that is how you
can enhance Scrum. In fact, I am doing a webinar in about four weeks, on
enhancing Scrum with Lean. Because then when you get stuck, you can say,
“Why do I have iterations?” And there are a variety of objectives, there
are reasons you have iterations.

When I am having trouble doing this one, maybe instead of just not
doing it, instead of don’t do Scrum but, I am going to look at, what is the
intention and how can I use Lean to get a better intention. There are two
kinds of Scrum buts in a sense. One is, “Well, we are doing some Scrum, but
it is too hard to do it this way, so we are going to, we are not doing
that.” And that is an accommodation, and that is virtually never good. Or
it could be well. “We are doing Scrum, but we cannot have fully cross
functional teams because one guy is needed for three teams.” So what we
have done is we have setup a Kanban work for this person, so we can be
sure, he crosses the three teams. So you know, that is good Scrum work
because you are getting the intention of it. So, that is kind of my
approach, is I am always trying to figure out what works, and then pull
from, whatever mindset there is. But if you just pulled from the mindset in
principles, it gets too theoretical. I mean, I am good with that, but most
tell me what to do. I need to know what to do.

Interviewer: Something practical, something.

Al: So then, yeah exactly. So that you want to, “Well, here you use this
part of Scrum or you use that part of Kanban”, but it is really, you are
just solving the problem-based on the laws of nature, of software
development, as a phenomena. Anyway, that is kind of what I do.

Interviewer: So you mentioned briefly through that, you mentioned
talking about using Scrum within Lean or I cannot remember the exact words.

Al: Yeah, within the context of Lean.

Interviewer: Within the context of Lean, yeah.

scaling Scrum, is the inside the team, it works well. But across teams, it
has difficulties. So how do you solve that problem? Well, Scrum of Scrums
has been attempted.

Interviewer: Not terribly successful in my experience.

Al: Yeah, I have a standing request for anybody in the community to give
me one success of Scrum of Scrum working. And so far, I have got none.
Nobody has come to me. So it is like, just stop talking about it please
because if it does work, tell me and if it does not work, let’s stop
talking about it. But the reason it does not work, is inter-team dynamics
are quite different than intra-team dynamics, when it comes to decision
making. See, Scrum of Scrum works really well, when it comes to
communication. That is fine because then, you are just letting people know
and it is not a bad method. So, how would you coordinate teams? Well, does
not mean you do not do Scrum? Does it mean you have to do command and
control and a high big view, and the answer is no, of course not. You have
to use Lean at the high-level, to manage workflow. So you say, “What is the
biggest, what is the business increment we’re trying to deliver?” Think of
it from a corporate point of view, deliver value quickly. Now, how do I get
my teams to deliver value quickly? Well, maybe if I need to break the work
up, I need to break it up into way that teams can work together, so they
are working on the same things at the same time. Because if their working
on unrelated things, like in the first sprint, and then they work on
unrelated things in the second sprint, you cannot integrate, you cannot
test, if you have got it working.

These are all the dependent things, “First we are going to do that,
then we are going to do the next sprint, that are related to each other.”
Then you are shortening the time, you are cutting out the delay between
building something and then, validating it. So if you say, you want me to
use Lean to make sure that my workflow is quick. I get something started
and done, started and done, then I can now do Scrum within that context,
that is what I mean by doing it within the context of lean. I also mean,
recognize that the reason Scrum works in my opinion, is not so much that
you have self organizing cross functional teams, but by having cross
functional teams. You basically cut out a lot of the amount of work in
process you have, and a lot of delays you have, inherently. Well if you
recognize that, then when you have a backlog for the Sprint, what you will
want to do is, even if you are not managing work in process, you will still
say, “I want to have as few stories open as possible” because it is Lean
concept. Then I will do things just in time, instead of all at once. So I
am doing Scrum, but I am doing it within these kind of rules and things
like that. That actually helps a lot.

There was one thing that crossed my mind, I was talking to you, just
to kind of float it through, but it was just as good a concept. To explain
this about Scrum within Lean, but I guess hopefully it will come back. That
happens to me, at times. If I said everything that was on my mind, you
would have about three conversations going on at once. Sometimes something
goes through there, and I can’t say it, I cannot remember what I said.

Interviewer: Happens to all of us.

about it, if you do Scrum or if you do Kanban, you can mix those two
together, as long as they are within the bigger picture of concept, context
that you are working on. So that is what is really good. So in a lot of
ways, the intention becomes, does not matter if you call it Scrum or
whether you call and Lean or whether you call it Kanban, the real question
is, why are you doing it. And the labeling is, just so you can talk about
it like a process pattern. So to me, Scrum is a process pattern. Kanban is
a process pattern, Kanban method is a process pattern and XP is a process
pattern. But that assumes, you are coming from the perspective that in
fact, there are laws of nature, of software development out there. Not
everybody agrees with this by the way. This is where Ken and I would
disagree, if we ever talked about it. We have never had that option. There
are many in the Scrum community, that do not believe, you can talk about
workflows and value streams, without causing a lot of problems. I
personally think you can, because I have seen it, I have done it, it helps.
But there are a lot of people that think you become mechanistic if you do
that. And it is possible, to become mechanistic.

I think Kanban method can become mechanistic. I have written about it
in a blog I call framework myopia, where, if you focus on one thing, then
you tend to ignore other things.

Interviewer: That is right, yeah.

Al: And our whole physiology, I usually do not try to study psychology.
Actually I study psychology and physiology a lot because, just as a hobby.
I think it is really fascinating stuff. I got a background in psychology, I
have always been interested in psychology but. It is interesting, if you
study it, you will notice, the body, the brain, our whole physiology, our
whole cognition, is geared around focusing on one thing. We are designed as
beings, to focus on one thing. And we have some sensors that give us
peripheral vision and things like that, but in fact when you notice, if we
are in a fight or flight response, things just gel down to what we are
afraid of, we give our full attention to that. So the danger in software
development in my mind, is when you start focusing on one thing. And you do
not notice the other things. You just do not even see them. It is not like
to see them and discount them, they would never show up in your cognition,
in your consciousness. And that is what I meant by myopia. Because myopic
people, they see something, but it is very limited and they cannot see
around it. And we are kind of becoming that way.

So, that is my latest rant, is I’m trying to get people. How do you
see what you need, and then how do you learn how to see what you need next?
And this is something that neither Scrum nor the Kanban method talk about.
Scrum just as we’ll start removing impediments, but they do not tell you
how or what. Kanban method says, work in process and you will figure it
out. Okay great, but why should I? Because you are smart and we respect
people. And I am saying, well if you respect me, you would not make me
reinvent the wheel. See that is another difference in attitude. I respect
people, I do not want them to waste their time figuring out what other
people have figured out. To me, that is wasting their time. So there are
differences and those differences are actually, it is not the difference in
Scrum or Kanban or Lean. It is the difference in those mindsets, how do you
help people, how do you learn, how many things do you focus on? Are there
rules to software? What are those rules? Those are the differences.

Interviewer: And so you mentioned, just briefly about rules of
software. That software has natural rules. Could you expand on that a
little bit? Because that is kind of interesting.

Al: Yeah, there are not a lot of them, but there are a few that are
reaching. So one is, if you start work and then stop it, and then you pick
it up later, that will cause more work to be done. And people call this
task switching, and it is not. You test switch every morning, you go from
seeping to waking. So if I work on something Monday, and then I put it
aside and I pick it up on Tuesday, task wise. If I stop working on
something Monday, and I pick up something else on Tuesday, I task switch.
If I work on one thing a day, that is minimal task switching. But if I work
on project a on Mondays, and then I work on project B on Tuesday and then
project C on Wednesday and I come back to A on Thursday, I will not be as
efficient, as if I work on A Monday and Tuesday and Wednesday, until I
finish it. It has to do with short-term versus long-term memory. And it
creates additional work for two reasons.

One is, I do not remember where I was, but what is worse, someone
else might have been in my code or somebody else might have changed the
requirement and I cannot get the response I want, fast. So that is a rule
of software, that if you delay the work flow, where it is not in your
advantage to do so. I mean sometimes, “Oh my brain is fried, I have got to
set this down.” Okay, and that is good. But I am talking about
interruption, talking about, I am working on something, I stopped, I go do
something else, I am not coming back to it, that will cost me time. If
requirements age, if I get some requirements today, three months from now,
they are not as good. That is not your opinion, that is not my opinion,
that is just the way it is, those are the things I am talking about. If I
work on really, really big things, in parallel with each other, it will not
work as well as, if I get something done and finish it.

The Agile community and the Agile manifesto refers to some of these
things. But it does not make it clear and explicit enough. For the example,
finished code is a better measure than have I got some artifact in front of
me. Yeah, it is not my opinion it is not your opinion, it is just the way
it is. That is what I mean when I say, it is not our opinion about it. We
have nothing to say about it. You can like or dislike gravity, but it is
still gravity. How you talk about it, might make you more effective in
dealing with gravity. But whatever phenomenon is out there, it will pull on
your, regardless of what your opinion about it is. So there are things like
that in software, that a lot of people are actually denying. They are
saying, “Well it is complex.” And I am not using complex in the Cynefin
model or even, they are not exactly consistent. Cynefin or [inaudible
00:26:01] talks about it being, “You cannot get cause and effect.” And the
answer is, it is actually not what it means. It is not what complexity
means. There are patterns to complex things, and you can get some cause and
effect, you just do not get exact predictability. I can guarantee you, if I
go into a movie theater and scream fire or scream bomb, or shoot a couple
of shots in the air, I am pretty sure, they are going to leave, and
screaming and yelling is going to happen to.

What exits they go to, I cannot predict that. But there are certain
patterns of behavior, you can definitely predict. So, even complex systems,
there are rules. The cause and effect may not be totally clear, but that
does not mean there is nothing. It just means we do not necessarily
understand it, but we can sometimes see big pictures of things. So this is
an area, that people have pretty much ignored, not everybody. Don
[inaudible 00:26:56] book, I have not read it. Principles of lean product
development flow, this is like a bible of software engineering. It is just
an amazing tone, definitely read it. It is Don [inaudible 00:27:08],
principles of. It is [00:27:11] book. I thing it is, principles of Lean
product development.

Interviewer: I will look it up, I will look it up on Amazon post it to
the community.

Al: Yeah, it is not an easy read, I will warn you. Principles of product
development flow, second generation Lean product development. But it is
brilliant, it is a brilliant book. Lots of equations, lots of graphs and
stuff. But it is not hard to read, I think is very clear, but you have to

Interviewer: You have got to give it your full attention?

Al: Yeah, it is not something you. You have got to give it your full
attention. But if you give it your full attention, then you will understand
it. It is very well written. Whereas I have read some books like, the Gang
of four book, when I first read that, I was like, I was giving it my full
attention and I was hitting a brick wall. But six months later, I got this
insight, that broke that the whole thing open for me. But I read that for
months saying, “I know that there is some good stuff in here because I can
smell it, but I do not see it yet.” That was an interesting, that was a
design patterns book. That was a book that was really up to, has
brilliance. Then when you break the code, it becomes, “Oh my goodness, this
is such an amazing book.” But it was very difficult to get to that point.

Interviewer: So just taking a quick step back, just to trace through
your path, through Scrum and through Lean as well. You mentioned right at
the very start, you were introduced to extreme programming by Martin
Fowler, and then you moved into the Scrum community. At what point were you
thinking heavily on Lean? Because I seem to remember that we chatted at
Amazon on, in 2008 and you were already starting to think quite heavily in
the Lean fashion.

Al: It was about 2004-2005, that I started getting into Lean in a big
way.

Interviewer: So that was quite early on actually?

Al: Oh yeah, yeah. Because the basics of Lean, I had in 83. I used to
study Deming, back in 84. It was actually 84. So when Mary, I met Mary
before the book came out. She was also in the Scrum community and we
chatted a lot, back then. So I made the connection with her back in 2002-
2003, heavy in 2004. And so Lean made immediate sense to me. It was like,
“Wow, this just explains a whole bunch of stuff.” And I could never get Ken
interested in going down that path. And every time I would talk to him, he
would say he was interested, and then when it actually came time to action,
it was always well, “No, I am doing my thing.” We never could agree. And
then, for a year or two, I was like, “Man, I really hope the Scrum
community will absorb Lean and move in this direction.” But since nobody
was interested, then after a couple of years I started thinking, “Well I am
nobody else is doing anything about it.” So apparently, it was okay to talk
about it inside the community. But once I started talking about it outside
the community, people did not appreciate that. Because they could not
control it, I guess.

So when we started in 2008, I had already been doing Lean for a few
years. My problem and it was right about that time that it started shifting
for me. My problem was, I just had Lean as a theoretical framework, that I
could sometimes intuit solutions out of. And I did, there were some things
that we did, that were really cool, really remarkable. And when I look back
on it, I recognize, I was managing flow well, and a variety of things like
that. But it was not until I started doing Kanban, which was right around
2008, that I started having a set of practices, that would implement these
principles. Then I understood the principles, but I did not understand, how
you would actually manifest it. On hindsight it is like, wow, I do not
quite see how I missed it, but I did. So I have David to thank for that
because he made it really clear. Actually, he did not invent Kanban, but he
was the one who promoted it. There were a couple of hundred people like
Orbis and Microsoft, who invented it. But you know, the same way that Ken
did not invent Scrum, Jeff did. Ken formalized it and so, around 2008-2009,
all of a sudden I had a way to make Lean work, from a practical point of
view.

And at that point though, I did not truly appreciate the importance
of teams. So I kind of went from heavy Scrum to heavy Lean. And then I do
not know, couple of years ago, I went back to, more mid-range. Believing,
teams are great, always try to get to them if you can. And jump as far as
you can, but you do not over jump. So, the Kanban method rather, of always
doing incremental improvement makes sense, if that is all you can do. But
it does not make sense if you can actually rearrange workflow, use minimum
business increments or whatever. And this is where David and I started
splitting up to some level, as I started talking about. “Well the Lean
method is great, but it is just one of many things.” And he did not want to
hear that. So, basically what happened to me… [voice stops abruptly]

[music]

The post Interview with Al Shalloway of Net Objectives appeared first on Scrumology.

Categories: Blogs

Agile Management Blog - VersionOne - Tue, 03/25/2014 - 21:36

Guest post by Mary Gorman & Ellen Gottesdiener of EBG Consulting

In a recent interview in the New York Times, Panera Bread co-CEO Ronald M. Shaich talks about the importance of de­veloping an organization’s “discovery muscle” as well as its “delivery muscle.” [1] Most companies have worked hard to perfect delivery—how they get work done—he says, because delivery “feels rational, people feel much safer with it, and you can analyze it.” But discovery—the activities you undertake to define or change your product, service, or market—is about “leaps of faith. It’s about trusting yourself. It’s about innova­tion.” The key, Shaich says, is for the discovery muscle to be at least as strong as the delivery muscle.

He took the words right out of our mouths. This need for balance between discovery and delivery applies in spades to software development. Our new book, Discover to Deliver: Agile Product Planning and Analysis [2], explicitly makes the case for equally balancing your commitment to these key ac­tivities. We define the relationship between them: In lean/agile software development, discovery and delivery are interwoven, interdependent, continuous activities (see figure 1). Each feeds the other.

Figure 1: Discovery and delivery are a continual process.

Traditionally, software teams have been out of balance—strong on delivery but weak on discovery. As a result, they tend to deliver technically excellent software that, unfortunately, may solve the wrong problem, possibly lags the market, or oth­erwise falls short of meeting the stakeholders’ real needs.

If your team needs to develop its discovery muscle, it’s not really about making a leap of faith. It’s more about making a leap of learning. Let’s look at why and how.

Context Counts

Many teams set themselves up for failure by not including discovery in their process from the very beginning. Before you begin talking about product options (aka requirements), the stakeholders need to hammer out a product vision and goals.

One of your most useful discovery tools is constructing and asking good questions to set the context and determine your mark. What is your company strategy, and how does your vi­sion for the proposed product align with it? Should the strategy be revised in light of recent developments? What is your problem or opportunity? What is the competition doing or not doing? What is your competitive advantage? Are you being too safe? Might there be customers beyond your current market? Who cares?

Figure 2: The product partners need to represent diverse viewpoints.

The vision activity should include people who represent three realms: the business, the customer, and the technology group—all of whom we call the product partners (see Figure 2). They need to collaboratively contribute to the vision.

The Lean/agile practices we use position value as the chief criterion for planning which product options to develop next. Of course, you’re not working at the level of product options yet, but now—while you’re developing the product vision—is the time for the partners to define their value considerations. A few examples:

Customer Value Consideration: Save time, money, and frustration.

Business Value Consideration: Support our growth strategy.

Technology Value Consideration: Ensure a scalable technology platform.

Working Together

Discovery is a team sport, not a spectator sport. Your dis­covery team must include diverse voices and perspectives. The partners collaboratively expand their thinking, look at the problem with fresh eyes, and consider new or unique possibilities. They reach far and wide. They listen to differing perspec­tives and reach agreement. You gain two benefits: (1) you exploit the wisdom (attributed to Aristotle) that the whole is greater than the sum of its parts, and (2) the product partners collectively own the discoveries.

As you collaborate in discovery, it’s important not to bow to conventional wisdom. It’s easy for your discovery muscle to shorten and tighten if you don’t stretch it. Instead, critique the way you’ve always done things. Be courageous, creative, and curious. Find out why. Moreover, as Shaich notes, defying con­ventional wisdom may help you discover something that gives you a competitive advantage.

Holistic Discovery Practices

Discovery engages the partners in learning and possibili­ties—it demands problem-seeking and solution-finding. To that end, your discovery process should address the product needs for each of what we call the “7 Product Dimensions” (see Figure 3 below).

Figure 3: Discover all 7 Product Dimensions.

Discovering all 7 Product Dimensions gives you a holistic understanding of the product’s functional and nonfunctional needs. You explore options within and across each dimension. This cross-dimension perspective helps inform and balance your discovery.

During a recent discovery workshop at a health care pro­vider, the partners quickly identified “obvious” users such as health care members and health care providers (e.g., physi­cians). Digging deeper, they discovered the health care medical director, who has unique product needs. Then they considered the users in light of the other dimensions and discovered new interfaces and environments, along with related actions, data, control (business rules), and quality attribute options. This discovery work provided a number of benefits. The partners’ shared understanding of the broad range of product possibili­ties helped shape the overall architecture, saving future rework. It guided their research on usability needs for complex data-visualization interfaces. And they reduced risk by collectively selecting the high-value options for their first release.

In conjunction with the 7 Product Dimensions, you use the “structured conversation” to frame your discovery sessions into three activities: explore, evaluate, and confirm (see Figure 4 below).

Figure 4: The structured conversation guides your discovery work.

The structured conversation is a lightweight framework that guides the product partners as they learn about the prod­uct’s possibilities and decide what to deliver. You explore op­tions for all 7 Product Dimensions. As you evaluate the ben­efits and risks of each product option, you use the partners’ value considerations to identify high-value options. You also confirm the partners’ understanding of the options.

And importantly, at each new planning session you’re open to exploring, evaluating, and confirming new product options, using your learning from prior deliveries. Thus, the structured conversation helps you balance your discovery and delivery muscles by moderating between the expansive thinking of dis­covery and the more focused thinking of confirmation and de­livery.

Engage Creatively

Discovery is the rich interplay of creativity, new or expan­sive thinking and human-centered design. You stretch your discovery muscle, making way for purposeful serendipity.

This aspect of discovery is often referred to as “design thinking,” a newer term for diverge-then-converge prac­tices that inspire, boost, and challenge the partners. Design thinking draws from an amalgamation of disciplines such as visual design, professional facilitation, architecture, industrial engineering, contextual inquiry, participatory design, impro­visation, learning games and simulations, and the burgeoning innovation and creativity movement.

Discovery goes beyond writing stories. Design matters. A lot. Your product’s look, feel, color, and aesthetic appeal—its visceral likeability—matter. Space and tools matter, as well. You “uncube” physical space so that people can conveniently and extemporaneously interact as they converse, sketch on posters, walls, or whiteboards, and select from and play with colored posts, markers, and glue to find possibilities and ex­plode problems.

To get there, you can draw from the family of facilitated workshop activities—variously called collaboration activities, serious games, Innovation Games, and more—to spark possi­bilities and yield serious outcomes. You can also use sketching, brain writing, affinity mapping, or card sorting activities. Tech­niques such as personas, role play, contextual inquiry, empathy maps, and journey maps help you gain affinity with your users, and you can employ analysis models such as prototypes, state diagrams, data models, and dependency graphs to tap into vi­sual thinking.

Figure 5: You can use various discovery tools and techniques according to the planning view.

You need to adjust your discovery scope depending on your planning horizon—what we’ve termed the Big-View, Pre-View, and Now-View (see Figure 5 above). You might not necessarily start from the top and work down, as long as you have a clear defi­nition of your discovery scope.

In the Big-View (the longest planning horizon, up to two years), your discovery muscle needs to be loose, flexible, and far reaching. At this planning horizon, you discover high-level, generalized possibilities for the product, across all 7 Product Dimensions. You might want to start discovery with a vision statement for the product, or your discovery might lead you to craft the vision.

In the Pre-View (the middle distance, or release view, pos­sibly a few weeks to a month), your discovery muscle is toned and controlled. Your discovery is framed within a clearly de­fined space to explore, evaluate, and select high-value product needs to enable planning for the next release.

In the Now-View (the shortest view, typically the next itera­tion: days or weeks), your discovery muscle is taut, ready to spring or sprint. You are focused on a narrowly defined space. You need to discover and define high-value product require­ments in sufficient detail to enable immediate development and potential delivery.

To get the most from discovery, be prepared to stretch, reach, bend, and twist the way you think about your product. At first, you may find training your discovery muscle uncom­fortable, even unpleasant. Or the partners may not be willing to discover together. Yet, regularly exercising your discovery muscle improves flexibility and range—you will see your busi­ness through different eyes. You will develop skills in discovery and innovation, building muscle memory so that discovery be­comes natural, seeming to progress without conscious effort.

Warning: As with any routine, your initial enthusiasm for discovery may dim with time and repetition, and your discov­eries may be less powerful. If that happens, look for new ways to spark creativity. Vary your techniques, inject new ones, and play innovation games. Switch roles, and take on a different perspective. Get out of your comfort zone.

“Your discovery muscle needs to be fit and ready to move, explore, and innovate to exploit opportunities.”

Reaching a Shared Understanding

The 7 Product Dimensions and the structured conversation are essential tools that enable the people in the three partner realms to agree on which discovered product needs are high value. The 7 Product Dimensions construct, for example, em­ploys a visual language that all the stakeholders can use in talking about the product. And because of the structure in the structured conversation, the partners become intimately ac­quainted with the incremental nature of the Lean/agile process.

So, what’s the biggest mistake we’ve seen that obliterates the benefits of these powerful tools? Failing to include the right people from beginning to end. The resulting siloed conversa­tions cause people to develop different—often conflicting— definitions of the product to be. Discovery becomes haphazard and undisciplined, scope changes often, and people retreat into the apparently safer, saner world of delivery. As a result, op­portunities to make a great product fizzle out.

It’s a Process, Not an Event

At any given time—this year, this release, this iteration— you may discover new product possibilities. That’s the nature of discovery. This means that your discovery muscle needs to be fit and ready to move, explore, and innovate to exploit op­portunities.

In the process we advocate, you move your discoveries into delivery so you can validate the value of the product options you chose. You assess what you deliver, and you validate what you have learned. Did the result deliver the anticipated value? If so, keep doing what you’re doing. If not, then loop back using your validated learning to feed subsequent exploration and experimentation.

Successful software teams deliver great products because they invest in ongoing discovery as well as delivery. With fre­quent exercise, their discovery muscle becomes stronger and more limber and works smoothly in tandem with their delivery muscle.

mary@ebgconsulting.com

ellen@ebgconsulting.com

Categories: Companies

### What’s Wrong With Your Questions?

TargetProcess - Edge of Chaos Blog - Tue, 03/25/2014 - 19:59

There’s one totally non-technical skill that is indispensable  in the life of any IT organization, at all levels. It is a great personal asset, likewise. A keen observer can use it as an accurate indicator of an individual’s professional intelligence. This skill is called the art of asking good questions.

We ask questions any time when we’re involved in an activity that requires input and knowledge of many people, at all kinds of meetings.  Stakeholders, product owners, UX designers, developers, QA engineers, marketeers — all of them have to master this skill to be able to make their best contribution to the success of the whole company. I’m talking about  a company that welcomes input from all team members.  Unfortunately, more often than not, little attention is paid to the quality of the questions that people ask during discussions. As a consequence of such loose attitude, hundreds of hours are wasted as the group’s focus shifts to irrelevant things.

Usually, it can be felt on some gut level, if a question is spot-on, or if it’s pointless. Someone might ask a question with a conscious (or unconscious) intention to show off to the others how smart they are, and their question wouldn’t help at all to get to the core of the problem at hand. Or, one can see that this person lacks experience, required to solve this problem, as their questions might seem naive to someone who is competent in the subject discussed. It might make sense, then, to let this person gain more experience, prior to taking part in the group’s discussion. Or, it could be that someone with a different outlook asks a question, that looks clueless to the group involved in a discussion, but this question would somehow invoke a fresh perspective, helping this group come up with a solution eventually.

One can compose many volumes trying to cover all possible kinds of questions, and mapping them with professional skills, personal qualities and organizational contexts. I will only single out these two fundamental faults:

1. Asking “how to” questions prior to “what for” questions.  This is the surest indicator of a wrong focus. Here’s an example of such a question: “How to adopt… [agile, Kanban, Lean, XP, Scrum, ..] in our organization?” If a stakeholder asks this question and has a vague idea of the “what for” part, the “how to” question shifts focus further away from the heart of the matter. Or, “how to estimate in story points?” Again, what for? Actually, if someone in a team, or the whole team, is asking such a question, this is a sign that they haven’t done their homework with the “what for?” part. If a team feels the genuine need to estimate in story points, the “what for” has already been processed, producing an array of possible answers to the “how to” part. These answers would stem from the unique experience and production dynamics of this particular team; and there’s no one finite answer, as each of the possible options would have to be tested “live” to see if they work.
2. Asking “what if” questions that involve some unrealistic or irrelevant scenarios. For example: “What if we fail to adopt Kanban this year”? This question has the double dose of “wrong” in it, because instead of an answer it generates 3 more questions: Who says we need to adopt Kanban? Why this year? What is our definition of “fail”?  Such a question is the biggest time waster. Hypothetical questions might only have some value, a rather questionable one, in talk shows or in celebrity interviews. If a question asked at a group meeting or discussion triggers a chain of even more questions,  that make no sense in the context of the current discussion, this question can be considered a waste.

The same logic can be used to hone this very art of asking questions. If someone understands the “what for” (I need to be able to ask good questions, what for?),  the “how to ask good questions” part will naturally take care of itself. With time. It only takes learning by experience.

Categories: Companies

### SAFe and Other Frameworks for Scaling Agile: A Case Study

Agile Management Blog - VersionOne - Tue, 03/25/2014 - 19:12

The following is a guest post from Brad Swanson, VP and Sr. Agile Coach at agile42

Scaling agile is one of today’s top challenges for many. I hear it from our customers all of the time. When agile and non-agile worlds collide within an organization, time to market and software quality often suffer. There are a number of fans in favor of the Scaled Agile Framework® (SAFe™) as the solution. I want to point out that while SAFe is highly effective for some organizations, it may not be the solution that’s best for you — OR you may be going about it the wrong way.

Introduction

We recently worked with a leading cable TV company that faced long and challenging development cycles with software quality problems. Guided by a small team of coaches*, they successfully implemented the Scrum framework with SAFe to scale up to 150 people delivering their set-top box/DVR software and server-side systems to support the DVRs. The following challenges drove the need for change:

• 12+ month release cycle; unable to respond to a rapidly changing marketplace
• Missed delivery dates; schedule slippage
• Quality problems due to late integration and 3 concurrent versions in development

Agile methods and SAFe reduced time-to-market for major releases from 12+ to only 4 months, the shortest practical timeframe, given the cost of deploying firmware to over 11 million DVRs nationwide. Releases changed to fixed-date; scope was managed and prioritized to ensure that all business capabilities were delivered on time, even though some low-priority features (‘bells and whistles’) were cut to meet the delivery date. Quality improved significantly as a result of earlier and more frequent integration testing, which is fundamental to the agile approach. SAFe was tailored to the organization’s unique needs after piloting elements of it on a smaller scale.

Here’s what we learned:

• The Agile Release Train model is effective for coordinating efforts of multiple, tightly integrated teams toward a short-term delivery.
• Many elements of SAFe can be eliminated or scaled back when teams are working on decoupled or only loosely integrated products, features, or components; the Program level in particular may be excessive.
• SAFe is sometimes implemented in its entirety in a “big-bang” change. This is possible, but extremely challenging and risky. Our  recommendation is to implement elements of SAFe in pilot mode to address known pain points, empirically determining which elements work and how, rather than pushing unproven changes to large swaths of the organization.
Scaled Agile Framework overview

The Scaled Agile Framework web site thoroughly describes the SAFe model. SAFe defines three levels for scaling an Agile organization:

1. Portfolio
2. Program
3. Team

At the portfolio level, Lean-Agile principles are applied to balance workload with delivery capacity and optimize value delivered, while aligning architectural efforts. At the Program level, product features are integrated and tested often by a System team. At the team level, multiple agile teams build and test small features within a single business domain or system component, and deliver running, tested features (user stories) on a set cadence (usually every 2 weeks) to the System team. SAFe prescribes fixed released dates with variable scope using the release train metaphor; if a feature misses the train (the date), it has to wait for the next release train.

Other frameworks for scaling agile methods are also useful in many contexts, including Disciplined Agile Development, Large Scale Scrum from Larman/Vodde, and Scrum of Scrums.

Managing change: evolution or revolution?

At agile42, we recommend an incremental and empirical approach to introducing agile practices at scale, rather than prescribing one particular framework to implement. Scaling lean-agile practices is a complex problem and every organization’s context is unique. Long-term success is more likely with an empirical and evolutionary approach, as described in agile42’s Enterprise Transition Framework™.

(1)                Assess challenges to identify specific needs for improvement

(2)                Pilot changes in a low-risk way

(3)                Empirically measure the results of the change

(4)                If the pilot succeeds, expand the practice more broadly

(5)                Repeat…

In the cable TV case study, agile practices were first piloted by 2 teams. We tried many of the SAFe practices throught the pilot efforts and used the lessons learned to guide the expansion of agile and SAFe.

Where the full SAFe framework was excessive

A different agile42 client, a financial institution, issued a corporate mandate to implement SAFe. In this case, teams did their best to implement all of SAFe in a “big-bang” rollout. It became clear after a few releases (4 months) that significant portions of SAFe were unnecessary, and even counter-productive in their context. Their 5 teams were each working on mostly independent applications, and there was no need for the overhead and coordination of a Program-level agile release train so they abandoned it, allowing teams to operate more independently. An evolutionary approach could have helped this organization learn what parts of SAFe were applicable in their context, in a less disruptive manner.

Reducing time to market

In our case study, the cable TV company changed their release cycles as shown in Figure 1.

Figure 1 – Product development cycle before and after

The agile development cycle uses the release train concept from SAFe. Releases have a fixed date, and scope is selected — and adjusted if necessary — in order to meet the deadline. If a feature misses the train, it has to wait for the next train. By aggressively prioritizing scope throughout development, and frequently integrating and testing, this model ensures that a viable product with the most important features will be ready on the planned date.

Portfolio Planning

The R&D organization started with a list of over 150 requests for features (projects) from the business. Senior leadership formed a Product Council consisting of 10 Product Owners (product managers), each of whom was aligned with a particular business area, plus R&D Directors. The Product Owners each made a ‘sales pitch’ for the highest value projects/features in their own domain, and the Product Council stack-ranked all the requests that might fit into a 4-month development cycle based on ballpark estimates. Ranking was accomplished by first scoring each request on a number of criteria: importance to business stakeholders, alignment with strategic initiatives, and cost of delay (urgency). This objective scoring cut the number of ‘contenders’ down to a more manageable number, from which point the Council members used a multi-voting technique to arrive at a final ranking.

Agile team structure

See Figure 2 below for a description of team structure before and after. Before agile was introduced, most of the people worked in large teams organized around technology components: the DVR (client) component and several back-end server components. Most of the business features however, required both client and server.  As a result, there was no clear ownership of the end-to-end business value. In the agile model, most of the people were organized into smaller feature teams (purple in Figure 2 below), each one owning features across client and server for one area of the business. One component team on the server side remained focused on building a major new architectural service. To maintain design integrity across feature teams, virtual platform teams coordinated designs across all the feature teams, as shown by the dotted line boxes  in Figure 2.

At first, the management team thought it wouldn’t be possible to form small cross-functional feature teams because each one would require too many people across too many specialties. So they put the names of every person on a separate card and began moving them around, trying to form feature teams of 10 people maximum. The managers were surprised to find that could form feature teams with only few gaps in skill sets and a handful of specialists (such as DBAs) who would need to serve multiple agile teams. Some organizations have accomplished the same structure through self-organization: allowing all the team members to collectively choose teams, rather than having a few managers do it. This organization wasn’t quite ready to embrace that idea.

Figure 2: Team structure before and after

Release train (4-month) planning

Figure 3 below gives an overview of the release train timeline.

Figure 3: Overview of the release trains from portfolio planning to delivery

• 4 weeks of portfolio planning
• 2 weeks for each team’s independent release train planning
• 1 day for all agile teams to build a combined plan for the release
• 4 months for building and testing – using 2-week sprints/iterations

With the portfolio priorities clear and team structure decided, each new team spent about 2 weeks doing high-level release train planning. Each release train was a 4-month period culminating in an integrated delivery from all the agile teams. Each Product Owner decomposed high-level business requests (features or projects) into smaller pieces (called stories), and prioritized the stories. The newly formed teams independently estimated the scope they could deliver in 4 months and identified dependencies on other teams.

The entire R&D organization (about 120 people) gathered in one room for the 1-day release planning event, except for one team that joined remotely by video conference.

1-day release planning agenda:

• VP of R&D shared the vision and goals for the upcoming 4-month release train
• Marketplace of collaboration: Each of the 10 teams had a large, visible timeline of features they planned to deliver in 4 months. People circulated between teams to better understand synergies and negotiate dependencies. (See Figure 4)
• Each team adjusted their plan to reflect newly discovered dependencies and adjusted scope
• All agile teams combined their release plans into a single visible timeline covering the 4-month period. (See Figure 5)
• A retrospective on the 1-day event: lessons learned to improve the next one.

Figure 4: One team’s release plan on the wall; collaboration with other team members

Figure 5: Combined release train plan for all 10 teams

Delivery Sprints

Each team worked in 2-week sprints (development iterations) throughout the 4-month release train.  The system test team integrated the work of all teams every sprint to test new features and run a regression test on the entire system. Some tests were automated but many required manual validation of video. The Product Owners from each meet met biweekly (once per sprint) to coordinate their work; additional team members participated when necessary. The final 2-week sprint was a ‘hardening sprint’ with all hands on deck to perform final regression testing.

Results
• The release was delivered on time with 100% of planned business capabilities delivered and 95% of planned low-level features included.
• Quality was higher than previous long-cycle releases: fewer total defects total and fewer severe defects were discovered post-release.
• The 1-day release planning event was an overwhelming success. People really appreciated the opportunity to understand the big picture and quickly reach a common understanding of the goal and scope of the release.
Challenges:
• Forming feature-oriented teams was initially viewed as impractical due to the large number of specialists required to build the perfect team. Through many rounds of name-swapping, we arrived at a set of teams that each was focused on a single business value stream and consisted mostly of full-time dedicated people. A small number of specialists spread their time between multiple teams to fill specific gaps.
• Regression testing every 2 weeks was possible only because the organization had invested in test automation. Still, some testing was manual and incremental testing was a significant shift for the system testing team.
• One of the feature teams struggled to integrated the client-side and server-side developers into a truly integrated team. They reporting structure and culture separated those two disciplines, and in practical terms they worked as 2 separate teams.
Conclusions

SAFe was an appropriate model for the cable TV company because multiple teams are all building a single integrated and complex product. Prior to adopting SAFe, the organization had already piloted Scrum on 2 teams with the help of experienced coaches, and learned how to make Scrum work in their context. This evolutionary approach to adopting Agile and SAFe was a critical factor in learning how to succeed in delivering on-schedule with high quality.

The experience of the financial institution, on the other hand, where  SAFe was mandated, demonstrates the risk of wholesale adoption of a prescriptive framework without first piloting changes on a smaller scale and measuring the results. The financial institution learned that much of SAFe was overkill in their context.

Key takeaways
• The release train model is effective for coordinating efforts of multiple, tightly integrated teams toward a short-term delivery.
• Many elements of SAFe can be eliminated or scaled back when teams are working on decoupled or only loosely integrated products, features, or components; the Program level in particular may be excessive.
• SAFe is sometimes implemented in its entirety in a “big-bang” change. This is possible but extremely challenging and risky. Our  recommendation is to implement elements of SAFe in pilot mode, evolving as you learn which elements work and how, rather than pushing unproven changes to large swaths of the organization. The agile42 Enterprise Transition Framework™ takes the evolutionary approach.

*Many thanks to the team of coaches who joined me on this effort: Manny Segarra, Deanna Evans, and Ken McCorkell.

Categories: Companies

### Organizational Learning Always Precedes Agile Maturity

Agile Management Blog - VersionOne - Tue, 03/25/2014 - 19:01

I’ve become increasingly convinced that a lack of learning is one of the largest inhibitors of agile transformation results.  One can argue that we are at, or nearing, the end of the knowledge era.  Knowledge is ubiquitous.  Simple possession of knowledge is not sufficient for either the individual or the organization.  Today’s rapidly changing business climate requires the coalescing of knowledge and experience into rapid learning that can be applied to problems and opportunities we can leverage for business value—quickly.

The amplification of learning is a key principle in lean and agile methods.  However, this is where traditional organizations making the switch to agile can very easily get in their own way if they’re not deliberate with their intentions.  Some of the best learning is obtained through failure.  For example, Thomas Edison failed several thousand times while attempting to find the correct material to create a filament for his incandescent bulb.  That means he learned several thousand ways of incorrectly creating an incandescent light bulb.  Large organizations strive to improve profitability and success through minimizing risk, which often results in a palpable fear of failure.  This fear can metastasize in an organization and impede learning and innovation.

So, how does this apply to agile transformations?  I’m sure everyone reading this blog has either read or heard someone say, “agile is not something you do; it’s something you are—a state of being.”  While I believe that’s true, it’s also a new way of working, one that comes with risk and inherently challenges the status quo.  Very frequently I sense an attitude in organizations that agile is “something the developers do” or “a new process that is being adopted in IT.”  The problem with this naïve thinking is that it will ultimately erode the results an organization might obtain, and frequently leads to failed agile initiatives.

For maximum impact and long-lasting results, agile should be embraced throughout the entire value stream.  This means from front-end customer contact (through Sales, Marketing, and Product Management organizations) all the way to the back-end of the value stream (IT operations and post-production support).  To do this requires a fundamental shift in how organizations are structured and operated.  It doesn’t have to happen all at once, but it does have to happen on a larger scale than the team level.  In fact, perhaps we should favor the scaling of agile values over the scaling of agile processes and practices.  Rather than, or perhaps before, asking how we can scale agile to the enterprise level, we should be exploring how we can scale agile thinking to the enterprise level.  Remember, individuals and interactions over processes and tools?

On the individual level, team members are sent to agile courses and are expected to deliver twice as much in half the time with a quarter of the budget.  Yet, when the course ends they are thrust back into an environment that has been structured to minimize risk and optimize predictability through rigid processes, massive reporting hierarchies, and unwieldy governance.  People tend to take the path of least resistance.  Therefore, especially when the pressure is on, they will do what’s necessary to get their jobs done.  Unfortunately, this often means working in the same manner they have always worked (status quo).

I think many of us can identify with these issues in some fashion.  It’s easy to become complacent, apathetic, and complain.  We see the problems around us.  But, what exactly can we do about it?  How can we, as individuals, impact change on a larger scale?  First, it’s important to understand that agile methods are exceptional at illuminating dysfunction.  I’ve heard individuals say, “how can we possibly deliver a working and fully-tested feature in two weeks?”  My response is typically, “working the way you currently are, you probably can’t.”  Expecting a major improvement in delivery without simultaneously experiencing disruption is unrealistic.  When organizations and teams begin implementing agile they will undoubtedly experience issues and frustration.  They will also make mistakes; this is learning.

The important thing to focus on is minimizing the probability that the same mistake will be made twice.  Too often the callous finger of blame is pointed at agile as either not being applicable (it just doesn’t work in our situation) or as the root cause of the issues.  We need to help our organizations understand that agile is not the root cause of many of these problems.  Make your first question, “What about this situation might be giving us pain?”  You will often find that you are clinging to practices that are grounded in traditional thinking but that run counter to the 12 agile principles outlined in the agile manifesto.  Challenge your teams to discover why they are having issues.  Retrospectives provide an excellent avenue to amplify learning.  And don’t be afraid to actually try something.  Learning is a verb; you must act on knowledge gained to realize improvement.

To help our organizations improve we need to conduct retrospectives at many levels within the enterprise, not simply at the team level.  To amplify learning we must help everyone, including the wider organization, become reflective.  Retrospectives can be applied to every level throughout the organization, especially at the leadership level as the organizational hierarchy plays a major role in enabling success.  If you’re a leader (and everyone certainly can be if they choose to be) and you’re not performing the actual front-line work of creating products and/or services that your customers consume, remind yourself often that you DO NOT deliver value.  Rather, you are a primary enabler of value delivery.  Help keep the organizational machinery well-oiled and finely tuned.

Try some of these practices to help your organization increase agile maturity.  Become a thought leader yourself and strive to learn all that you can.  But don’t stop there.  Propagate your learning to others.  You don’t need to do this through formal classes.  It can be done in simple hallway conversations and daily interactions.  Organizational learning is the aggregate of the actualized knowledge of every individual within the organization.  In its absence agile maturity will stagnate.

Categories: Companies

### VersionOne – An Idea Worth Making Simple

Agile Management Blog - VersionOne - Tue, 03/25/2014 - 18:04

Guest post by Michael Swansegar

“What’s the most resilient parasite?  An IDEA.   A single idea from the human mind, can build cities. An idea, can transform the world, and rewrite all the rules…which is why, I have to steal it.   Never recreate from your memory, always imagine new places.   He’s hiding something and we need to find out what that is   This was not a part of the plan.   Wake me up!  Wake me up!”

What if I told you that you have heard those words before?  Well you have, for a good portion of 2010. http://tinyurl.com/d8x8y83  Yes, this is the script for the trailer from the movie, “Inception.”  This movie captivated audiences across the globe.  Why?  It was structured to help people understand we are motivated by a highly secure, deeply entrenched idea that shaped our lives. Everything we do in life is built around ideas. Ideas are hard to forget, ideas change the world and inspire companies, nations, families and the most important person, YOU.  You were meant to change the world.

Well this script runs two additional things: it runs the agenda of an agile cultural event called Project Inception but this ‘script’ is the basis of how you could potentially view VersionOne.  As I take you through this ‘idea,’ I hope you see as I do, not only the value of an agile event but moreso the value of VersionOne, their culture, their product, and their belief in someone that can change the world, YOU.

Forget what you think you know.  Wait a second, that’s hard to do isn’t it?  Let’s do something different; let’s replace our focus on something simple.  The idea is this… replace every scripted plan, every requirement document, every business meeting, every statement of work with a simple question.  That question is simple yet bold, “Is this valuable?”  Is it, the product or service, valuable?  Let’s take it further. Are you acting and building in a valuable way?

Simon Sinek has a wonderful book called Start With Why.  In that book he relates a number of scenarios where companies became market dominators if they focused on why, the motivation, the ‘value’ concept, the limbic brain.  When someone says, “This doesn’t feel right…” that is a limbic brain response.

Where do I as an outsider see VersionOne?  Let’s take VersionOne’s tagline which states, “Agile Made Easier.“  AHA! Something real,something that makes you feel right.  If VersionOne said, ‘Agile Made Easy’ you wouldn’t feel right about that statement.  If you said agile was “easy,” someone might look at you and say, “Who lied to you?”  They are motivated to make agile easier.  That isn’t necessarily quantifiable with fact.  Making something easier is very subjective, but the IDEA is VALUABLE.  The idea is to make something easier, make it valuable, make it feel right so it is natural to you.  So the parasite has leached on to VersionOne and hopefully on to you.  Make things easier, make them valuable, period.

VersionOne takes it further. They believe, just as I teach at Project Inception, that agile is not about process.  The agile process simply comes along for the ride.  Agile is about loyalty, customer loyalty, your loyalty.  There is a reason why Apple has a cult-like following: they “think different.” They don’t tell you what they have; they tell you how they feel.  Apple’s products make you feel something. VersionOne produces services and an agile project management tool set that is built to inspire loyalty. BS?

Let’s take an analogy for a ride, shall we?  You own a mansion with a perfect yard (don’t we all?) and you never live in the house because you have to constantly work to pay for the house.  So what do you do?  You hire a neighborhood kid to mow the grass.  You may be rich, but you believe in using someone nearby – call it “co-located resources.” Well each week, this kid cuts your grass too low.  In fact, imagine you live in southern California where they have no water but plenty of forest fires.  So you know your product of value (the grass) will die a quick death.  Each week you have to over-water the grass so it doesn’t get scorched; call it a broken business process due to a P.O.S. product. Each week you give feedback and the kid doesn’t listen. Each week your grass is getting burned. After the 4th or 5th week, your neighbors are packing up their golf clubs and laughing at you since you can’t join them because your lawn is on the brink of death. Who is the idiot now?  Do you feel loyal to that kid anymore? Does that kid feel loyal to you?

How the hell does this relate to VersionOne? Well agile is about building something valuable to inspire loyalty, right? Every few weeks the product is ‘mowed’ by virtue of a product demo. Each iteration, as it were, you get burndown charts and burnup charts. VersionOne excels at a Scrum value called ‘Openness.’ Their agile project management tool brings visibility to either the problems or the successes.  If you chose to show your product and your status by means of an open tool like VersionOne, agile is easier because the parasite (value) is identified faster. Why?  ‘Openness’ assumes some other Scrum values of hearing your customer’s feedback with ‘Respect’ and then having the ‘Focus’ to hear what they feel in their limbic brain. This takes ‘Courage’ to hear painful failures at times, but this allows you to finally ‘Commit.’ You commit to building the right product and making the changes that will inspire the loyalty of that client.

Brain Science
Source why-agile.com

“Why”/The IDEA = Agile Made Easier = Value

“How” =  By holding true to agile values and principles in our services and tangible product lines.

“What” = We have a tool that shows value defined via stories, charts, graphs, planning, idea management and, most importantly, common sense.

Welcome to Maloney’s Rule, or “Accelerating Diffusion of Innovation.” In short, Marketing 101.  Your customers are hiding something from you.  You need to perform Inception on them. Still don’t know what that means? Watch the movie!  It means you go into someone’s dream/head and steal or replace an idea with your own. No, I am not encouraging espionage in companies, but I am encouraging you build your products and services to invite a customer to turn into a partner. Seth Godin (famous marketer) partly calls this stage the title of his book, Permission Marketing. When a customer “invites you” to come into their business, to see more problems and discuss solutions as a partner, you have reached permission marketing. When products or services have reached this stage, you look at Maloney’s Rule and see why it is carried through the curve.

Let’s look at the iPhone crazies for a moment:

Maloney’s Rule / Bell Curve
Source why-agile.com

GEEKS

They value being first and “early adopters.” They have a strong limbic feeling to the iPhone so they will buy the iPhone 6 the moment it comes out.  They will tell their friends if it is awesome. They blog, they tweet and they actually attend that two-hour commercial called the Apple Conference. Their limbic brains say “the product feels right; the only losing move is not to play.”

GENERAL PUBLIC

They value a product that fits a business need. They check to see the product ratings. They check their wireless contracts and ask themselves, “Do I really want to stay with AT&T or should I wait so I can move to Verizon?”  Their limbic brains say, “I don’t know about this contract; it doesn’t feel right.  Let’s wait to renew.”

GRANDMA

They value family and they aren’t too sure if technology is needed to actually come visit someone in person. They most likely won’t buy it. Heck, most of these people can’t even see. They still use AOL for shopping and play Bingo on Fridays.  Their geeky grandchild will give them the iPhone 5 or 4 or 3 saying, “Hey grandma, you want to see your grandkids grow up? I will send a picture of them to you every week.” Meanwhile, grandma can’t find the icon labeled ‘Messages’ to actually see the photograph.

So each user type, each partner on the curve, has different value statements.  This is what they are hiding,their IDEA, their VALUE statement.  Hello, Product Owners! Go extract that info, will ya?  Hello, VersionOne! Thank you for making a product with Ideas Management from the ground up.  You didn’t white-label some tool and slap it into your product, claiming it was yours.  Although if you were smart (competitors), you wouldn’t slap anything and take the risk of claiming it was yours.  VersionOne built Ideas Management inside the product because it is part of their DNA — to identify valuehence making agile easier.

Project Inception spends an entire morning on this topic so this is just the tip of the iceberg. It is good to know that if this just scrapes the tip, VersionOne must have an iceberg of hardened values we have yet to harness for our benefit.

Welcome to “top-down planning” or “the rolling wave approach” (PMBOK). Time to bring in the agile poster of VersionOne, which you can get here:  http://pm.versionone.com/AgilePoster.html

VersionOne stresses top-down planning in one of its truest forms. Noticed first, “Agility is…” starts at the top focused on the fuzzy things such as goals and vision.  Now you ask yourself, “How would I like this product released to inspire loyalty and encourage the spirit of collaboration with feedback loops?” VersionOne calls that the Release loop, which has its own estimation and lightweight planning stage.  Working with the customer to decide how they want to define value and potential delivery via feature-based delivery (see Blizzard Entertainment) or timebox-based delivery will inspire them to be a part of your culture and success stories.

Now comes the fun part: the first layer of reality, the “Iteration” phase where a review of the product and inspections or “retrospectives” give the partner visibility into who we are and why we exist, day in and day out. When a partner can open VersionOne and see human behavior via burndown or burnup charts, they are fully invested in your company — monetarily and mentally.  When a partner is interested enough to listen to how the team could behave better in a retrospective, you know they are no longer a paying customer but a loyal partner.  This loop is huge; it is where a business ‘fluffy’ executive can see first hand the impacts of business and technical competence colliding. VersionOne handles this phase with care and “Openness” to allow for visibility into the barriers to meeting defined value. The more visibility and accountability at this phase, the more you can leverage agile. To VersionOne’s primary parasite, it makes “agile easier.”

Looking into the daily activities, we can project into the future. We aren’t recreating from our memory; we are using data of there, here and now to “imagine new places.” The place, as it were, is the parasite… the idea of value in our partner’s mind for which we are constantly striving. Notice at the end, “Agility is… working software.”  That is all that matters; does it work? “Work” is defined as meeting the parasite — the idea of value, not just from a feature standpoint but also from a perception mindset.  That is really hard to do.  Again, agile is not easy; it can only be made “easier.”

How often have you heard this before?  It is used so often as an excuse to fail. Many people think it is a protective coat of armor. Well, when you are under water, the last thing you want is armor. You want to take everything off, so to speak, any weight, any unnecessary supposed asset – so that you can tread water. Don’t use this comment as an excuse to fail. If life were always planned, it wouldn’t be worth living. If agile were easy, everyone would do it. Better yet, everyone would be doing it properly. Look no further than VersionOne’s homepage.  I am not sure who approved this design, but if it was Dan, props to that guy. The message is loud and clear. Below is a screenshot taken of VersionOne’s web site.

“This wasn’t part of the plan!”

That’s OK, as long as all the projects and all the teams are in one place.  We can adjust; we can see the inter-dependencies. Besides, if this adjustment couldn’t be foreseen, we have bigger problems than the plan itself. We apply strategic thinking to our out loop, and let the vision and idea direct every motivation of our teams by bringing them together to believe in something.

“This wasn’t part of the plan!”

That’s OK. We have visibility across the entire software lifecycle. We see how test-driven development can catch changes and its associated risk nice and early. We see via in-depth reporting how the human impact will be felt at different layers on different teams. We can adjust the impact to be handled by the mature teams while protecting the ones that are fragile. We can see the output and protect its quality through our visibility. We are strong when most open and vulnerable to factual trends.

“This wasn’t part of the plan!”

We believe in in commitment, respect, focus and courage.  You can’t have that without collaboration, and that is why we have views between our teams (agile team software with “TeamRooms“) and Kanban boards. We aggressively hold each other accountable by openly challenging each other to hold their commitments. We collaborate naturally, but use agile team collaboration software to exemplify our natural-born gifts. We are focused on the goal at hand, and we allow nothing to creep in secretly by forcing our organization to openly show what is in the iteration and how we task each other to our most efficient capacity.

“This wasn’t part of the plan!”…     “You are correct, and that is why we are changing the plan.  We work on value, period.  Our partner trusts us to see reality and their needs change.  Perhaps you should start using a pencil   …instead of a pen next time?”

You see this in your typical workflow of agility at the customer demos.  The business doesn’t like to be surprised, so this shouldn’t be the first time you share your findings with customers. However, you can find blog posts on demo day all over the place. Let’s bring this back home instead of repeating content you have read elsewhere.

Inception: we have hopefully leached a parasite on you — an idea focused on value. In the sense of agile, we want you to feel the need to find what your customers are hiding… that tangible idea of value buried beneath layers and layers of security.

We have talked about looking at the limbic brain and understanding your partners’ feelings, and from a marketing angle why you can’t ignore the geeks who believe in something. We have carried the parasite forward, not wanting to latch on to the past, but always imaging new places. The place of value our customers dream about and our interpretation of that dream can be obtained by striving to have not only a process, but a culture centered around agility.

It’s time to wake up and understand a cold, hard truth: agile is not, nor will it ever be, easy.

However, Project Inception and VersionOne have a simpler goal: agile can be made easier.

Categories: Companies

### What’s the Right Ratio Between QA Testers and Developers?

BigVisible Solutions :: An Agile Company - Tue, 03/25/2014 - 16:55

I get asked this question all the time.  And I think that the answer is both obvious and not at the same time.  In any case, it’s not possible to answer what the ratio of developers to QA testers should be.  Here’s why.

Let’s take a look at a flowchart of how software development really occurs.

I know that there are differences in this diagram based on whether we are using “waterfall”, “Scrum”, “Kanban”, and so forth.  But the differences are usually that we don’t explicitly acknowledge the stage of process that we are in, or we subsume it in another process step.  For example, in eXtreme Programming, we tend to design, code, and functionally test all in one step. We use Unit Testing in Test Driven Development as the functional test in isolation, and the “refactor” step in “red/green/refactor” as a way to accomplish “design a solution”.

Where are the testers in that diagram?

That is, by no means, a trivial question, and it does vary based on the operating model that we use for software development.  In traditional waterfall development, we usually have testing occur by role.  Developers are typically assigned the responsibility to functionally test what they code, usually called “unit testing”.  In fact, most of what I’ve seen in the field is that those “unit tests” are usually simplified functional “spot tests” that never make it into any regression suite, rather than the eXtreme Programming type of unit tests used in Test Driven Development.  These spot tests are typically fast, throwaway, and unrepeatable.  The people in QA sometimes are called upon to do this testing.  The best that can be said is that we saw some version of code that made the code functional for its intended purpose at the point at which point the test passed.

Traditional waterfall type testing does employ QA testers at the “non-functional and regression tests” stage.  QA will typically write long test plans intended to ensure that functionality not only meets the functionality desired, but also does not have an adverse impact on either previously developed functionality or non-functional aspects of the software, such as speed, capacity, etc.

In a traditional world, market tests are typically not done by either developers or QA personnel.  That testing occurs only once the product has been released to the marketplace.  The testing occurs by the customers of the product.  Unhappily, the results of that testing show up as missed market expectations, and occur after any hope of fixing the software would be possible, as the product is now in the marketplace.

If we are looking for better quality, both in terms of assuring that the software is written correctly, as well as being the right code to solve the problems that customers need a solution for, you’re going to have to do two things.  You’re going to have to push testing forward, so the feedback loops occur quicker. You’re going to have to automate as much of the testing as possible, so that you can iteratively attack the problem, and not have huge amounts of labor to fix a product that is not on course with customer expectations.  I can’t count the number of times I’ve seen product teams cut out the software testing done after the code was developed so that it could be delivered on a date previously promised. They did it because the labor and time needed to exhaustively regression test the code weren’t on the timelines that were committed to.  Delivering buggy code to your marketplace is an excellent way to help your competitors capture your market. So is delivering on the wrong solution.  This means that shortening the cycle time for this diagram is critical to make this happen!

This diagram is way too simplistic

Absolutely!  In Lean terms, it is a single stream flow of one piece of required functionality within a product that a businessperson knows must be presented to the marketplace as a “minimum viable product”, a “minimum marketable feature”, or even something smaller.  Depending on the process that you use for software development, you may be tempted to have as many of these functionality implementations going on at once.  But that increase in WIP (work in process) causes its own set of problems.  If one piece of functionality is being developed that depends on another piece of functionality code, then dependencies start to rear their ugly head.  Having one piece of functionality take longer to develop than originally estimated can have compounding and confounding ill effects on the code depending on it.  The same is true of a solution that doesn’t “meet the mark” on the non-functional and integrated regression testing aspects.  Note that by waiting until “we are ready to release” before we start this type of testing, we potentially grow an enormous WIP of unreleased code.  Any failure at this stage has a lot more code to fix than if we were able to stay with an ideal single stream flow.

“Rules of thumb” are meaningless

You can find many rules of thumb for the ratio of QA to developers if you do a Google search with the words in the title of this blog entry.  You will find people talk about 10 developers to 1 QA tester, 3 to 1, 1 to 1, and many others.  My feeling is that none of these can possibly be correct.  They can’t be right, because they don’t take into account the abilities of both the developer and the tester.  Highly capable developers may be 10 or more times quicker at producing the same code as less capable team members.  The same will hold true for QA testers.  I had a conversation with Fred George a little over a year ago on this topic, and he recounted an assignment where he observed a ratio of 6 testers needed to absorb the work of one highly productive developer.

Rather than going that rule of thumb route, I would urge you to consider getting closer to a single stream flow on individual things that the software needs to do and employ the “Three Amigos” model that George Dinwiddie explains in Better Software, November/December 2011.  Here, we get the BAs, QAs, and developers at the start to write automated tests that serve as the functional requirements for the work to be done.  If we keep the rate of production of these collaboratively-developed tests in line with the actual rate of production that satisfies the tests, we never have to fear that we have something off balance.  If we find, perhaps with a Kanban analysis, that we can’t produce enough tests to keep our developers happy with enough work to do, we may find that we don’t have enough BA types or enough QA types available for us, and can adjust accordingly.

And, yes, there will always be a place for QA exploratory testing on integrated code.  But that should be automated as well into regression suites that are automated and repeatable.

Flow is the most important thing to a business

You may be asking yourself at this point, “Yes.  I get it.  I need to reduce WIP, and not worry so much about rules of thumb to get software done.  But what about that test in the market?  How do we get better at that?”  The answer there is easy – release more often!  And that will take your continuous integration solution to a whole new vista – continuous delivery, and engender a whole new set of problems that are wonderful to have, such as “how quickly can may market absorb new features, and how can I get them to accept things in a more laminar flow fashion?”

Businesses that produce software do it for a purpose.  Usually a pecuniary purpose.  Understanding the reasons behind why excessive WIP is such a dangerous thing to have may put the onus on the business to see how to incorporate smaller product tests, in terms of releases to the marketplace, more frequently.

Since there is no right answer to the question of “what’s the right ratio”, let’s invoke Kobayashi Maru sort of solution.  For those of you who never saw or have forgotten Star Trek II: The Wrath of Khan, the Kobayashi Maru was a simulation exercise that Starfleet put all of its officers through to test if they could save the civilians trapped in a disabled ship in the Klingon Neutral Zone.  Because of the constraints involved, no cadet at Starfleet academy had ever passed the test.  Even the legendary James T. Kirk failed the test twice, only passing it the third time by reprogramming the simulator.

We can’t win this battle for correct ratios between QA and developers by simple rules of thumb.  But we can fall back on the values and principals of Agility, just like Kirk did for Star Trek values and principles.  We need to focus on the team’s people and interactions (specifically, QAs, BAs, and developers) for as much work as possible up front to increase quality (the most efficient and effective method of conveying information to and within a development team is face-to-face conversation).  Keep WIP sizes small (working software is our primary measure of progress).  Test our code not just during development (continuous attention to technical excellence and good design enhances agility), but get it into the hands of customers quickly and often (customer collaboration).

Let’s change the conversation from one asking for rule of thumb ratios into one that asks for collaborative development, better quality, and faster market realization of smaller and smaller chunks of valuable software.  We can measure and find where WIP is causing resource constraints, and do the traditional 5 step Theory of Constraints solution to fix things.  In other words, let’s turn around the faulty question for an answer (that is bound to fail in practice) into a new quest to deliver, measure, and deliver more of what works.

Photo Source

The post What’s the Right Ratio Between QA Testers and Developers? appeared first on BigVisible Solutions.

Categories: Companies

### Valuable Agile Retrospectives: How to Do Them?

Agile Management Blog - VersionOne - Tue, 03/25/2014 - 15:16

Guest post from Ben Linders, Netherlands-based Sr. Consultant, InfoQ editor and bilingual (Dutch & English) blogger

At the end of an iteration, typically two meetings are held: The sprint review (or demo) which focuses on getting product feedback, and the agile retrospective which focuses on the team and the process used to deliver software. Agile retrospectives are a great way for teams to continuously improve the way of working. Getting workable actions out of a retrospective and getting them done helps teams to learn and improve.

To do agile retrospectives it’s important to understand what they are and why you would want to do them. This helps you to motivate team members to actively and openly take part in them. Many exercises exist for retrospective facilitators to design and perform a retrospective.

This blog post is based on Getting Value out of Agile Retrospectives, a pocket book by Luis Gonçalves and Ben Linders that contains many exercises that you can use to facilitate retrospectives, supported with the “what” and “why” of retrospectives, the business value and benefits that they can bring you, and advice for introducing and improving retrospectives.

What is an Agile Retrospective?

The agile manifesto proposes that a “team reflects on how to become more effective”. Teams use agile retrospectives to inspect and adapt their way of working.

A retrospective is normally held at the end of each iteration, but teams can do it as often as needed. It focuses on the team and the processes used to deliver software. The goal of retrospectives is helping teams to improve their way of working.

All team members attend the retrospective meeting where they “inspect” how the iteration has gone and decide what to improve and how they want to “adapt” their way of working and behavior.

Typically a retrospective meeting starts by checking the status of the actions from the previous retrospective to see if they are finished, and to take action if they are not finished and still needed. The actions coming out of a retrospective are communicated and performed in the next iteration.

To ensure that actions from a retrospective are done they can for instance be added to the product backlog as user stories, brought into the planning game and put on the planning board so that they remain visible to the team.

Why Do We Do Retrospectives?

Organizations need to improve to stay in business and keep delivering value. Classical organizational improvement using (large) programs takes too long and is often inefficient and ineffective. We need to uncover better ways to improve and retrospectives can provide the solution. Many agile teams use retrospectives: to help them solve problems and improve themselves!

What makes retrospectives different from traditional improvement programs? It’s the benefits that teams can get from doing them. The team owns the agile retrospective. They can focus where they see the need to improve and solve those issues that hamper their progress. Agile retrospectives give the power to the team, where it belongs! When the team members feel empowered, there is more buy-in from the group to do the actions which leads to less resistance to the changes needed by the actions coming out of a retrospective.

Another benefit is that the team both agrees upon actions in a retrospective and carries them out. There is no handover, the team drives their own actions! They analyze what happened, define the actions, and team members do the follow up. They can involve the product owner and users in the improvement actions where needed, but the team remains in control of the actions. This way of having teams leading their own improvement journey is much more effective and also faster and cheaper than having actions handed over between the team and other people in the organization.

Retrospective Exercises

How can you do retrospective meeting that delivers business value? A valuable agile retrospective identifies the most important things that a team wants to work on to improve their process. But what is most important? It can be the biggest, most current impediment your team has. Maybe something is disrupting your team’s atmosphere and they can’t get a hold of it. Or it could be finding the reason why the current iteration failed, or why it was such a big success.

Teams differ, and also the things that teams deal with can be different in each iteration. That is why there is no single retrospective exercise that always gives the best results. Also the risk exists that teams get bored when they are always doing retrospectives in a similar way. A solution to this is to introduce variation using different retrospective exercises. So before starting a retrospective, you need to think about which exercises would be most suitable.

The retrospective facilitator (often the scrum master) should have a toolbox of possible retrospective exercises and be able to pick the most effective one given the situation at hand. Here are some examples of retrospective exercises:

• An easy but powerful exercise is Asking Questions. There are many different questions that you can ask in retrospectives. The trick is to pick the ones that help the team gain insight into the main and urgent issues and identify improvement potential. Then, by asking more detailed questions, it allows the team to dive even deeper into the retrospective.
• The Star Fish is a variant on the “What went well?, What did not go so well?, What can be improved?” exercise. The Star Fish retrospective use a circle with 5 areas to reflect on what activities the team should stop right away, what activities the team should continue with in a reduced role, what activities should be kept, what activities should play a bigger role in the future and what activities the team should start.
• The Sail Boat is an exercise to remind the team of their goal the product they need to deliver, the risks they might face, what is slowing them down and most importantly, what helps them deliver great software. It uses a metaphor of a boat, rocks, clouds and islands.
• The moods of team members are often affected by problems encountered while working together. Having team members state their feelings in a retrospective using the Happiness Index helps to identify possible improvements. This exercise uses a graphic representation of team members´ emotions.
• If there are significant problems that a team wants to avoid in the future, you can use Five Times Why exercise. This exercise uses root cause analysis to get to the deeper causes of problems and to define actions that address them.
• A Strengths-Based Retrospective visualizes the strengths that your team members and teams have using a solution-focused approach. It helps to explore ways to use strengths as a solution to the problems that teams are facing.
• When you have an agile project with multiple teams, you can do a Retrospective of Retrospectives to improve collaboration between teams. This is an effective way to share learning’s across a project and to solve problems that a project is facing.

Our advice to retrospective facilitators is to learn many different retrospective exercises. The best way to learn them is by doing them. Practice an exercise, reflect how it went, learn, and improve yourself. Feel free to ask any question about retrospectives.

Valuable Agile Retrospectives

Agile retrospectives are a great way to continuously improve the way of working. We hope that this blog post helps you and your teams to conduct retrospectives effectively and efficiently to reflect upon your ways of working, and continuously improve them!

Our book Getting Value out of Agile Retrospectives and the related blog posts and articles mark the beginning of a journey. We are growing a small ecosystem to release more exercises in the future, How To´s, retrospectives´ advices and many other things. If you want to stay up to date, the best way is to subscribe to our Valuable Agile Retrospectives mailing list.

You can download the book Getting Value out of Retrospectives free of charge from:

Ben Linders is a Senior Consultant in Agile, Lean, Quality and Process Improvement, based in The Netherlands. As an advisor, coach and trainer, he helps organizations by deploying effective software development and management practices. He focuses on continuous improvement, collaboration and communication, and professional development, to deliver business value to customers. Ben is an active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer. He is an editor for Agile at InfoQ and shares his experience in a bilingual blog (Dutch and English). You can also follow him on twitter at @BenLinders.

Categories: Companies

### Introduction to Business Capability Modeling

Leading Agile - Mike Cottmeyer - Tue, 03/25/2014 - 13:24

In any Enterprise-scale Agile transformation, having the right structure and governance to support how work flows through the organization is crucial to having a successful transformation (see “How to Structure Your Agile Enterprise“). Business Capability Modeling is a method LeadingAgile uses to inform and customize our recommendations around this structure and governance. We work closely with our clients to develop their unique business capability model. We then heat map the capabilities in terms of business value, performance, and risk, based on interviews with key stakeholders. The resulting heat-mapped capability model promotes a shared understanding and can be used as a basis for how to structure teams (what to form the teams around) and for prioritizing and scoping work.

The Capability Model is a modular description of a business in terms of desired business outcomes. Desired business outcomes are identified and defined at each level of detail in a hierarchical fashion. So for example at the highest / top level of the hierarchy we would have for a typical business capabilities like “Develop and Manage Products and Services”, “Market and Sell Products and Services”, “Deliver Products and Services” and “Manage Customer Service”. Complementing these operational capability areas are supporting capability areas like “Develop and Manage Employees”, “Manage Information Technology”, and “Manage Financial Resources”. The American Productivity and Quality Center (APQC) is a member-based, non-profit that provides a “Process Classification Framework” (PCF) from which these examples are taken. LeadingAgile works with the client in a process of discovery to identify the client-specific capabilities, using the APQC PCF as a reference model.

The capability names are chosen to be action oriented, written in a verb-noun format, like “Acquire Inventory” or, “Authorize Customer”. The descriptions are written to define the desired business outcome, like “Maintain enough inventory to support demand”, or “Enable registered customers to use the system”. There are likely  one-hundred or more capabilities across 5-10 or more major areas such as those listed above. This gives us a very useful model since it describes the business in terms of its “Whats” and not “Hows”. We need to avoid the “How Trap” when discovering and defining the capabilities. It’s so easy to go down a rat hole of discussion around how a business outcome is achieved. We want to stay focused on what needs to be achieved. This gives us an objective model of the business upon which we can have objective conversations. Meaning, without getting into how capabilities are achieved since that ties us to the current implementation.

As mentioned, the Capability Model provides a modular, outcomes-based description of the business. As such, this is naturally a Service Oriented model or view of the business. So, the business processes made up of the capabilities could be implemented in software with a Service Oriented Architecture. Thus, for greenfield development, the Capability Model could be used to help drive a Service Oriented Architecture (SOA)/ design and implementation. For legacy systems, it can be used to refactor the legacy architecture to be more Service Oriented, in addition to the other uses listed above. To learn more about Capability Modeling and SOA, see the Harvard Business Review paper “The Next Revolution in Productivity” by LeadingAgile’s Dennis Stevens, et al.

————————————————

Also check out a recent post where Mike addressed the questionIs Your Business Model is a Good Fit for Agile

Categories: Blogs

### Questioning beliefs

Growing Agile - Tue, 03/25/2014 - 09:00

You all know that I love agile and all things agile. Every now and then its a good exercise to question the things we hold so dearly. I figure this might be an interesting thought process so I’m blogging as I think through it.

Can I question the agile manifesto? Mmm perhaps I should take a more aggressive approach and defend the opposite. That might open my mind to more ideas. Here goes:

We are uncovering better ways of developing software by doing it and helping others do it.Through this work we have come to value:

I suppose you are entitled to your opinion. I am sure there are many people in the world who believe they have uncovered better ways of developing software. Wow. This is quite difficult – feel like I’m dissing my community. Pushing on …

Individuals and interactions over processes and tools

So I totally get that people are more important than machines and ideologies. But we are building SOFTWARE. Thus we are computer people, who love online tools. Most of us run our lives using these tools. We trust the tools we develop with, usually more than the random person the company hired to work with us in a team. As a developer I am good at what I do – so let me do it. I don’t want to do your job of analysis and understanding. I want to do my job of making it work. Just had a lightbulb moment in understanding some developers anti-agile stance.

Working software over comprehensive documentation

I believe in noting things down – when I don’t I inevitably forget about them. Thinking through a problem space and carefully noting all the things that need to be done is due diligence. When you think through a problem and spend time there, actually doing the work to solve the problem is easy. Of course I still want working software, I just think having a well thought through document will solve 90% of the problems. This was a bit more tricky, I really don’t like verbose documents. But if I think of it as a thinking tool I can make sense of it.

Customer collaboration over contract negotiation

I know the customer is always right, but blindly following the customer – who probably doesn’t know what he wants without a contract is business suicide. How will you make money if there is no agreement (legally binding) of how you are trading services for cash. As a customer I want to know how much something is going to cost me before I commit to paying. I need to talk to other vendors and compare prices. I need to know what you will give me for my hard earned money as opposed to someone else. Ok getting into the flow of things now, this one felt easier. It helped to think of my upcoming house renovation and what I’m needing as a customer.

Responding to change over following a plan

Everything I do in life has a plan. Yes they change – but not by much and only when something goes horribly wrong. And my plans cater for some ‘problem’ time. Following a plan gives me certainty to whether I’m on track or not. It lets me know and plan for other things in the near future. Of course I want to respond to change – but only if it affects my plans end goal not for the sake of change. This one was much easier. I do believe in plans, and I love responding to change, however I’ve seen how quickly a project can get messed up by only responding to change.

EXERCISE OVER!

OK so lets see what I’ve learned.

1) It’s fairly easy to justify almost any sentence and provide examples of why you’re ‘right’.

2) Even the things I believe in wholeheartedly can be wrong at times.

3) I shouldn’t judge those who believe differently. I should seek to understand – as they probably make a lot of sense.

That was fun, and challenging What do you believe in? Can you question and defend an opposing argument?

Categories: Companies

### Organisational Inertia - A Predictor for Success of Agile Transformations? (Part 2)

Xebia Blog - Tue, 03/25/2014 - 02:30

In part 1 (Organisational Inertia - Part 1) I have focussed on the question: 'Organisational Inertia - What is it?’. This blog addresses the question ‘How do we measure it?’.

I'll start from the definition of Organisational Inertia as defined in part 1. Then connect to existing models of Organisational Inertia and the relation to Agile teams and show how the analog with Physics is used to find a measure for the 'acceleration'. Then I'll combine these elements to provide a way of measuring inertia. Finally I'll provide basic examples.

Definition of Organisational Inertia

Following the analogy with physics I defined Organisational Inertia in Organisational Inertia - Part 1 as:

DEFINITION

Organisational Inertia is an organisation’s capability to change after applying some force to it. Specifically, I define it as the ratio of the force applied and the speed of organisational change (acceleration) in reaction to some applied force, or in formula "Inertia (M) = Force / Acceleration".

We just shifted the problem of defining Organisational Inertia to defining ‘some applied force’ and ‘speed of change’. The next sections will provide an interpretation of these in the context of Agile teams and a model to describe 'some applied forces'.

Origin of the Forces Driving Organisational Change: Change Restraining and Change Facilitating Forces

Associated with Organisational Inertia are two competing forces as described in the Inertia model of Connor & Lake [Con88] (see also [Kin98]). This model describes the Change-restraining forces and the Change-facilitating forces.

The model recognises that there are forces that hinder change and that there are forces that facilitate change.

One of the Agile principles is to regularly reflect on how you are doing and improve. By doing so Agile teams not only improve over time but they change too. An Agile team that changes will force the environment to change with it.
For more detailed information on this, check out the ‘fitness landscape’ [App11] chapter 15 “How to improve everything”.

Another common way Agile teams force the environment to change is by pulling more work in than the environment is capable of delivering. Or, by pushing more working software into production and thereby literally pushing the limits of what the environment is capable to process. The latter mechanism drives organisations towards DevOps [Deb11]. The combination of applying a force to both the up- and down-stream teams is what drives the need for BusDevOps (Agile Delivery Model), see Agile Delivery.

Examples I often see in practise of how Agile teams force the organisation (or environment) to change include:

• a faster delivery rate forces the environment to cope with more releases and simultaneously forces the business to keep up by supplying user stories at a higher rate,
• raising impediments,
• the business wants more features than IT can deliver (this often drives the need to transition form a traditional way of working to an agile way of working).

For a systemic view on cause and effect related to Organisational Inertia see e.g. [Lar96].

How (Agile) Teams Act As Change-Facilitating Forces

Agile teams continuously improve. The way they improve I divide in 3 types. With each type I associate a 'force'. The next section will go into details of quantifying them.

In Management 3.0 [App11] chapter 15 “How to improve everything” the concept of the ‘fitness landscape’ is explained. In this metaphor the team is part of the landscape (the environment of the team within the organisation) in which the team optimizes a certain variable, for instance the business value it creates. The optimum is symbolised by the highest mountain peak. Through improvements the team finds its way to the highest peak. Besides team intrinsic changes the team can also change the environment and thereby change the landscape by moving mountains towards the team instead of moving towards the mountain.

Following this metaphor there are three ways for a team to reach the top of the highest peak:
I) gradually improve (changes intrinsic to the team),
II) large improvements (kaikaku) and jump to other (nearby or remote) mountains, or
III) change the environment, i.e. moving the mountains to the team.

Agile teams regularly evaluate how they are doing. A common practise is to perform a retrospective every two weeks. In the retrospective the team decides what to change and executes these improvements in the next sprint (or time period). With these improvements the team walks the ‘fitness landscape’ to the nearest mountain peak. The improvements may be gradual and internal to the team. By this we mean that it increases the velocity and does not force the environment of the team, i.e. the organisation, to change. The team does not exert a force to the organisation.

Large Improvements (Type II Changes)
It may also be the case that the improvements within the team either dramatically increase the velocity or many gradual improvements increases the velocity over a certain threshold. When this happens - in my experience it is not a question whether this will happen but rather ‘when’ - it will force the direct environment of the team to change with it.

For example, when teams start to deliver user stories faster the business needs to keep up by having enough user stories ready.

Another example is that operations needs to keep up by putting more features into production.

This way the team applies a force to the surrounding organisation that needs to change as well. The team is not just walking the ‘fitness landscape’ but forcing the landscape to change as well [App11].

Moving Mountains (Type III Changes)
The third way for teams to apply a force is to raise impediments and have the organisation help them by addressing the most important impediments. By structurally solving impediments the organisation is changing the ‘fitness landscape’ [App11] by moving the mountain peaks to the team.

With 'structurally solving impediments' I mean that solving the impediments requires company policies to be changed.

An Organisation’s Speed of Change

The final part is to have a way of measuring the speed of change while the Agile team exerts a force upon the organisation. Before we can answer this question we need to identify how to observe that an organisation changes. Possible variables are:

• the trend of the (average) resolution time of impediments,
• change in the rate of bringing features to production,
• change in the rate of taking work to the team(s),
• company policies being changed.

Potentially this could become a long list. But are all these changes relevant? Ultimately it’s the bottom line that counts. It’s all about the outcome. Let’s try to come up with variables that are of value to the business. This is pretty close to the bottom line. At least close enough. Variables that come into mind include:

• change in the rate of business value per unit of time,
• change in rate of an organisation’s (agile) maturity rating,
• change in rate of product incidents per unit time.

These are all variables that can be measured and are the (complex) outcome of the changes made.

The choice depends on the goal that you want to achieve with the (agile) transition. As long as this is communicated clearly to the organisation and progress is being made as measured using this or these variables, you are measuring the rate of success and there will be enough energy in the organisation to continue the transition and avoid Organisational Gravity kicking in.

Metrics for Organisational Inertia

From the aforementioned examples we recognise the following metrics for the 'forces' (Change Facilitating):

• [F1] the number of raised impediments per time period, e.g. per sprint or per month,
Force = <Number of Raised Impediments per Period>,
• [F2] difference in rate (throughput) for pre-sprint, sprint and post-sprint parts in a so-called cumulative flow diagram,
Force [F2a] = <Business Value Delivered in Production per Period> - <Work According to DoR Worth of Business Value per Period>, or
Force [F2b] <Business Value Delivered in Production per Period> - <Work Completed according to DoD Worth of Business Value per Period>

Force [F2a] measures the 'strength' with which the (Scrum) team is pulling work from the Product Owner. A positive value means that the PO cannot keep up with the team.
Force [F2b] is similar for the IT-Ops - (Scrum) team interaction. Positive values indicate the (Scrum) team is pushing work for production at a faster rate than the organisation is capable of taking into production.

The associated metrics for measuring the 'acceleration' (speed of change) are:

• [A1] the trend of the average number of resolved impediments per time period; count only resolved impediments that required changes in company policies,
Acceleration = Δ(<Number of Resolved Impediments per Period>)/<Period>,
• [A2] the trend or change in the rate of business value (outcome) delivered per time period,
Acceleration = Δ(<Business Value Delivered in Production per Period>)/<Period>.

The metrics just given are readily available to Scrum teams and can easily be applied to any team, kanban type of system, or to any part of the total value stream.

Putting It All Together

Using the results of the previous section I quantify Organisational Inertia in terms of measurable variables available to (Agile) teams.

Gradual internal improvements that the team makes (Type I changes) often lead to Type II changes after a certain period of time. Therefore I only explicitly address Type II and Type III changes (as explained earlier).

Are We Moving the Mountains? (Type II Changes)
Taking the change facilitating forces as a basis the Organisational Inertia is derived as follows.

First, consider the metric for inertia ( $M_\mathrm{org}$ M_\mathrm{org} ) based on business value, i.e. [F2b] and [A2] from the previous section. Combining these gives:

$\langle\text{Value delivered per Period}\rangle - \langle\text{Value ready (DoD) per period}\rangle = M_\mathrm{org}\times\Delta(\langle\text{Value delivered per period}\rangle)/\langle\text{Period}\rangle$ \langle\text{Value delivered per Period}\rangle - \langle\text{Value ready (DoD) per period}\rangle = M_\mathrm{org}\times\Delta(\langle\text{Value delivered per period}\rangle)/\langle\text{Period}\rangle

What does this formula tell us?

• if the team’s delivery rate balances the organisation's rate of putting features into production no force is exerted and the organisation will not be forced to change; then also no change (Δ) in the delivery rate,
• if the team delivers more functionality than the organisation can take into production, the team exerts a certain force upon the organisation which needs to undergo structural improvements causing a positive change (Δ) in the delivery rate,
• for small values of the inertia ( $M_\mathrm{org}$ M_\mathrm{org} ) the effect on the change in delivery rate is larger.

Note: A  unit of  measure for $M_\mathrm{org}$ M_\mathrm{org}  is ‘time’, e.g. 'weeks' or 'sprints' for Scrum teams.

Example 1. Suppose that the team delivers 5% more business value each sprint. Suppose further that they deliver 20% worth of value faster than can be taken to production. Then the inertia is ’4 sprint’ (20% divided by 5%).

Example 2. Suppose that no change in the rate of delivered business value is measured. Then the Organisational Inertia is infinitely large; under a change facilitating force it does not change.

The effect of Organisational Inertia on delivered business value

Example 3. Suppose an inertia of ’4 sprint’ (Example 1). Further suppose that the team pushes 20% worth of features per sprint more than can be taken into production. Then it will take $M_\mathrm{org}$M_\mathrm{org} /20% = 20 sprints to double the production rate.

Example 4. As in the previous example, the graph to the right shows the same team but in an environment in which the inertia is twice the inertia of the other environment. The team in the environment with the least inertia delivers value at a rate that increases twice as fast as compared to the other team. This results in twice as much business value being generated.

Are the Mountains Moving? (Type III Changes)
Another possibility is to take impediments as a basis to define and measure the Organisational Inertia ( $M_\mathrm{org}$ M_\mathrm{org} ):

$M_\mathrm{org} = \frac{F_1}{A_1} = \frac{\langle\text{Number of Raised Impediments per Period}\rangle}{\Delta(\langle\text{Number of Resolved Impediments per Period}\rangle)/\langle\text{Period}\rangle}$ M_\mathrm{org} = \frac{F_1}{A_1} = \frac{\langle\text{Number of Raised Impediments per Period}\rangle}{\Delta(\langle\text{Number of Resolved Impediments per Period}\rangle)/\langle\text{Period}\rangle}

Note: Only impediments that actually result in changes in the organisation should be taken into account.

Note: This can also be translated in terms of business value by estimating how much more business value the team would be able to put into production if the impediment is resolved.

Note: The unit of measure is ‘time’, e.f. 'weeks' or 'sprints'.

Conclusion

Organisational Inertia is supplementary to the concept of Organisational Gravity and an indicator for how well the team’s environment is facilitating the team’s growth. The two counter balancing driving forces of the speed of organisational change are the Change-restraining and Change-facilitating forces.

An indicator available to agile teams for the Change-restraining forces is the average number of solved impediments per time period. Change-facilitating forces are the forces that teams exert on their environment. Indicators available to agile teams are the amount of pulling from the business for more ready features and pushing completed work into production.

Using the interpretation of the formula $F=M A$ F=M A , well-known in physics, in terms of the Change-restraining and Change-facilitating forces as defined in the model for Organisational Inertia from Connor and Lake  [Con88], and identifying $M$M with $M_{\textrm{org}}$ M_{\textrm{org}}  expressions for Organisational Inertia are derived.

Once the organisation's inertia is known, this can serve as a prediction how long it will take to increase the organisation's delivery rate with a certain amount and is related to the business case of Agile Transformations.

References [App11] Management 3.0, Jurgen Appelo, 2011, Pearson Education, [Deb11] Devops: A Software Revolution in the Making, Patrick Debois, August 2011, Cutter IT Journal, Vol. 24, No. 8, http://www.cutter.com/promotions/itj1108/itj1108.pdf, [Con88] Managing organization change, P.E. Connor & L.K. Lake, 1988, New York: Praeger, [Kin98] The development of an instrument for measuring organisational inertia, C Kinnear, G Roodt, Journal of Industrial Psychology, 1998, 24(2), 44-54; see http://ujdigispace.uj.ac.za/handle/10210/1047, [Lar96] The Dynamics of Organisational Inertia, Survival and Change, Erik R. Larsen, Alessandro Lomi, 1996, System Dynamics conference, http://www.systemdynamics.org/conferences/1996/proceed/papers/larse308.pdf
Categories: Companies

### Remote profiling Neo4j using yourkit

Mark Needham - Tue, 03/25/2014 - 01:44

yourkit is my favourite JVM profiling tool and whilst it’s really easy to profile a local JVM process, sometimes I need to profile a process on a remote machine.

In that case we need to first have the remote JVM started up with a yourkit agent parameter passed as one of the args to the Java program.

Since I’m mostly working with Neo4j this means we need to add the following to conf/neo4j-wrapper.conf:

wrapper.java.additional=-agentpath:/Users/markhneedham/Downloads/YourKit_Java_Profiler_2013_build_13074.app/bin/mac/libyjpagent.jnilib=port=8888

If we run lsof with the Neo4j process ID we’ll see that there’s now a socket listening on port 8888:

java    4388 markhneedham   20u    IPv6 0x901df453b4e9a125       0t0      TCP *:8888 (LISTEN)
...

We can connect to that via the ‘Monitor Remote Applications’ section of yourkit:

In this case I’m demonstrating how to connect to it on my laptop and am using localhost but usually we’d specify the remote machine’s host name instead.

We also need to ensure that port 8888 is open on any firewalls we have in front of the machine.

The file we refer to in the ‘agentpath’ flag is a bit different depending on the operating system we’re using. All the details are on the yourkit website.

Categories: Blogs

### 7 Days of Agile Results: A Time Management Boot Camp for Productivity on Fire

J.D. Meier's Blog - Mon, 03/24/2014 - 22:06

An amazing thing happens when you become more focused and productive ...

You get more out of life.

It’s like you have 27 hours out of the day, while everyone else has 24, and they spend 8 of them sleeping, while you spend them dreaming of what’s to come next.

Too many folks have too much to do with too little time and they can't keep up.

We don't necessarily learn great time management skills in school or on the job, and we don't necessarily learn how to really blend our time, energy, and action to produce our best results.

That's where Agile Results steps in.

Agile Results it the underlying approach showcased in my best-selling book on time management, Getting Results the Agile Way.

It's a simple system for meaningful results.  It helps you cut through the clutter to get to what matters, and to use your best energy for your best work.  I put Agile Results together over a period of 10 years while testing principles, patterns, and practices that push the envelope in terms of high-performance, extreme productivity, work-life balance, stress management, and well-being.

Here’s What You Get by Using Agile Results:
1. Proven practices to master time management, motivation, and personal productivity
2. Discover the one way to stack the deck in your favor that’s authentic and works
3. How to embrace change and get better results in any situation
4. How to focus and direct your attention with skill
5. How to use your strengths to create a powerful edge for getting results
6. How to change a habit and make it stick
7. How to never miss the things that matter most, and achieve better work-life balance
8. How to spend more time doing the things you love
The 7 Day Boot Camp for Agile Results

I put together a simple time management book camp to help you just start using Agile Results.

For some case studies, stories, and testimonials see http://gettingresults.com/wiki/Testimonials.

If you need more depth beyond the 7 day time management book camp, then check out:

And, of course, there’s always the book:

If you’re already an Agile Results master, share this post and help somebody else set their productivity on fire.  Help friends, family, and colleagues reach a new level of awesome.

Categories: Blogs

### Gourmet Crow, or Wearing a Different Hat

Practical Agility - Dave Rooney - Mon, 03/24/2014 - 20:00
For readers to whom English isn't their first language, we use the phrase "eating crow" to describe a situation when you must admit that you were wrong after taking a rather strong position about something. While this isn't exactly that case, hence the second title, it does illustrate a lesson in perspective. First Hat - "Sherpa" While I was working at Shopify, one area on which I focused
Categories: Blogs

### Scrum Daily Stand-up Meeting Troublemakers

Scrum Expert - Mon, 03/24/2014 - 19:28
The daily stand-up meeting is an important moment in Scrum project. Team members meet to know about potential challenges as well as to coordinate efforts to resolve issues. They usullay discuss the three following questions: What did I accomplish yesterday? What will I do today? What obstacles are impeding my progress? In this blog post, Derek Huether describes 10 types of persons that create trouble in the Scrum daily stand-up meeting. These type of issues might be minor like obsessive phone checking but also create more trouble like the people who ...
Categories: Communities

### Knowledge Sharing

SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.