Visual.ly InfographicUnderstanding why an organization thinks it needs to change is enlightening. Many times the people at the bottom ranks of the organization have no idea the driving forces that necessitate a change. As a group brainstorm a list of possible reasons for the change.
Dialogue on the difference between change and transition. How long does change take? What is a transition? Bridges Transition Model: Ending - Neutral Zone - New Beginning.
Dialogue on the difference between satisfiers and dissatisfaction in the workplace (Herzberg's Two-Factor theory).
See Gallup's Q12 Employee Engagement survey.
First just capture all the reasons that might be the answer to - Why change?
Typical reasons (if you need to prime the pump - or when the answers slow down - throw one of these out to head in a different direction).
- Current process just doesn’t work
- Decrease time to market for new products
- Cost reductions, improve effeciencies
- Scrum is the methodology of the decade (soup de-jour)
- We’ve tried all the others - maybe this one will catch on
- The boss said so
- Our competator is doing it
- Exponential change rate of market space requires ability to “pivot” into new market spaces with our existing products
- We don’t really know what our customers desire until we deliver it
- Outsourcing is hard so maybe this will fix it
- Our quality is too low - so Scrum will fix it
- Dot Vote - 3 dots each - which is the organization true motivation?
- 5 Whys? - Identify one item and ask WHY until you have a root cause motivation.
Intrinsic vs Extrinsic Motivation
Herzberg's Two Factor Theory
Interesting links on Motivation
First Break ALL the Rules.
Video series on Scrum (short takes)
A Release planning and Scrum simulation - Priates of the Carriballoonian
Project success sliders
Quikie video explains relative vs absolute measures
Dog Grooming - agile estimation technique
Elements of an effective scrum board - checklist
Pick the Metrics to use to evaluate your team
If your Agile and you know it - clap your hands. Prove it - show me the practices that support a claim of agility
Definition of Done & Ready
Intro the concepts of TDD & Refactoring
Create a set of well known plays for the team
Experience the power of prototyping and evolutionary design - Marshmallow challenge & video
Pair programming exercise - classic chess games
What Motivates your Employees
Make a classic PM iron triangle from plastic drinking straws
Backlog for planning your own company internal Agile conference
The missing affordances of a virtual task board
Product Owner workshop on Scrum with a simulation
Do you need a full time Scrum Master - take this test.
A game to discover your typical super hero role on a team
Resuming the DataViz 101 series started last year, I want to revisit some basics for data visualization, showing when we get value from having numbers visualized, and when such a visualization is inappropriate. One of the main reasons that data visualization exists at all — be it smooth infographics, or slick project reports — is the fact that it saves us time needed to digest some quantitative information, i.e. the information that has numbers in it. Visuals present numbers in an appealing way, making them easier to read. Sometimes, however, they use visualized numbers with no substantial ground. If no meaning is ingrained into the graphical cuteness, a visual would make no sense. Some other technique for information rendering has to be used then, such as a text.
Take a look at one such case where numbers pretend to be visualized with some meaning, while actually failing to provide real value to people who look at them.
One can see this pattern with numbers highlighted quite often on web-sites for conferences or gatherings. Such a visual is supposed, presumably, to convince potential attendees that this conference holds some value for them. However, I don’t see how it will help decide if a conference is worth attending or not. There’s no universal converter that would work for each and every individual, and translate those hours of keynotes, workshops, trainings, and the count of speakers into a meaningful answer to one question: “Will I learn something new and useful for me personally at this conference?” How are these flat numbers capable to attend to the unique knowledge landscape of any given individual? No way, they can’t do it. Those people who are looking to decide for themselves if a conference is worth attending or not, might as well skip this “hippish” part with meaningless numbers, and proceed straight on to the text piece about the speakers, keynotes, workshops and training. Bad news for someone who did this visual: they’ve wasted both their time, and the time of the site visitors.
Here’s the other example that shows how visualized numbers can help in project management:
This is a sparkline report, and while it includes numbers that seem to hold no meaning to an external observer, an insider who looks at the graph is likely to know the project context: how user stories and bugs are sized in general, how much effort does it take to have them completed, and how these numbers can be rendered into a diagnosis report on the project health. Compare the sparkline graph and this text: “This report covers the last 16 weeks. Designers had their backlog full with 13 user stories in the first week, with fewer and fewer new stories added in the next weeks. They completed 3 stories, and had 2 more added to their backlog in the current week”. Of course, the sparkline renders this info in a more compact and time-saving way.
As a summary, before we hurry to create a visual report, or an infographic with numbers, we need to consider if a user or a reader will get the info they want fast from this visual. Some information can be rendered best as a piece of text, like in this first example from a web-site of a conference. Words would have taken readers to the core of the matter faster. In the second example, it’s the other way round. It would take more time to convey the same information in words.
Sprintly was recently recognized by Software Advice as one of the top five favorite user interfaces in agile project management. Software Advice researched 100s of project management interfaces, selected their top five favorite and in the review called Sprintly’s interface “remarkably attractive.”
I had a chance to catch up with author Noel Radley to ask her a few questions about herself, how she found Sprintly and what were her primary drivers for selecting Sprintly:
Phuong: Will you give us some background on yourself?
Noel: I’ve been researcher since 2001 (PhD in English), covering topics of technology since 2007. I’ve also taught writing for over a decade at University of Texas at Austin and Santa Clara University. At both campuses, I led research in teaching with technology, including work in Drupal, electronic portfolios, and media production. In February, I joined Software Advice, where my primary research is project management software.
Phuong: How did you find Sprintly?
Noel: It was a rigorous process to select our five favorite softwares. We surveyed 100s of project management interfaces, and we deeply researched about a dozen.
Sprintly showed up as a popular project management interface, and repeatedly we found users commenting on the visual design. As we evaluated the interface, we agreed that it had earned its reputation for compelling design. It really stood out among project management softwares.
Phuong: What were the primary drivers for choosing Sprintly?
Noel: First, we were looking for interfaces that wowed us with beautiful design. Secondly, we were searching for interfaces that helped teams think in critical and productive ways about workflows. We liked Sprintly because it did both. The interface was stunning, while it also provided real insight to project teams.
It’s true there are many interfaces to help track development processes, but we wanted to search for ones that helped developers think in a new way. We feel Sprintly offers unique dashboard views that are conducive in prioritizing, decision-making, and adapting a development workflow.
For example, the Kanban style board is designed in such a way it doesn’t look like your typical card wall, which is refreshing. It also has functionalities your typical card wall may not have, since the cards are more obviously interactive and social than other boards we’d seen.
Phuong: From a UX and UI perspective, do you have any opinions on what a good agile project management tool should provide a team?
Noel: Our article focuses on UI design. To demonstrate great UI, we feel that an agile project management tool would have powerful visual metaphors to help the team conceptualize their work. The tool would be accessible with clearly labelled and categorized features. Finally, in terms of color and composition, the design would make it easy for the team to identify what aspects of the development were the most important at any given moment.
For development teams, the interface should make it easy for teams to view and adapt workflows in real-time.
From surveying these tools, we got a sense that agile project management interfaces are becoming more user-oriented in general. This seemed to indicate an innovative moment for these kinds of software, and the interfaces we selected were leading the way. We can’t wait to see what’s next!
Many time, in the middle of developing a user story, the programmer discovers a question about how it’s intended to work. Or the tester, when looking at the functionality that’s been developed, questions if it’s really supposed to work that way. I once worked with a team that too-often found that, when the programmer picked up the card, there were questions that hadn’t been thought out. The team created a new column on the sprint board, “Needs Analysis,” to the left of “Ready for Development,” for these cards that had been planned without being well understood.
It was that problem that the Three Amigos meeting was invented to address. Rather than wait until a story was in the sprint to fully understand it, stories that were on-deck for the next sprint would be discussed by representatives of the business, the programmers, and the testers to make sure that all the questions were answered before considering the story ready for development. Sure, the occasional question still came up during development, but the epidemic had been stemmed.
Since that time, I’ve found better ways to determine if a story is ready for development. I look for the list of essential examples, or acceptance scenarios, that the completed story will satisfy. These provide a crispness to the understanding of the story that’s hard to achieve any other way.
There are fringe benefits to going to this level of detail. Planning discussions of the story don’t spend a lot of time understanding what the story means. These discussions don’t go round-and-round finding the boundaries of the story. If the scenario isn’t listed, it’s part of another story (or it’s been overlooked). In fact, dividing the scenarios into groups is a simple way to split a story into smaller ones.
Another benefit is that the scenarios can be automated as acceptance tests prior to the development of the functionality. Having a clear picture of the outcome before starting helps keep the development on track, minimizing premature speculation of future needs and maximizing attention to current edge cases that might otherwise be overlooked.
In a development process that uses sprints or timeboxes, you’ve got the whole sprint to get the next sprint’s worth of stories refined prior to planning. If you’re practicing a single-piece pull process, you’ve got the length of time a story spends in the development input queue to do so. Either way, refining the backlog is a necessary overhead activity that should be done a little at a time, all the time.
The goal is to have the work done just-in-time for planning and development. It should be complete enough to avoid stoppages to build more understanding, but not so far in advance that the details get stale. We want our scenarios to take advantage of the most knowledge we can bring to bear. If done too early, we may have to revisit the scenarios to see if we need to alter them according to what we’ve learned since we created them.
More often than creating too many acceptance scenarios too early, I find teams spending this effort too late. It seems a lot of work to go to such detail when we know we’ve got a mountain of work to accomplish.
Developing software correctly is a detail-oriented business. We’re going to have to get to that detail sooner or later. Leaving it until the programmer has a question causes interruptions in development, delays, lost effort, and, sometimes, unwarranted assumptions that give us results we don’t want. Don’t look at the mountain of work. Look at the little bit of work we’ve decided to tackle next. Do a great job on that, and things will go more smoothly.
Here’s a short animated video describing Spotify’s engineering culture (also posted on Spotify’s blog).
This is a journey in progress, not a journey completed, and there’s a lot of variation from squad to squad. So the stuff in the video isn’t all true for all squads all the time, but it appears to be mostly true for most squads most of the time :o)
Part 2 hasn’t been recorded yet. Stay tuned.
The book: The 5 Elements of Effective Thinking by Burger & Starbird.
In the audio format I found it hard to visualize the 5 elements, perhaps because of the analogy to the classic elements of earth, fire, air, and water. So before any confusion sets in, here are the author's 5 elements:
- Grounding Your Thinking; Understand Deeply [Earth]
- Igniting Insights through Mistakes; Fail to Succeed [Fire]
- Creating Questions out of Thin Air; Be your own Socrates [Air]
- Seeing the Flow of Ideas; Look Back, Look forward [Water]
- Engaging Change; Transform Yourself [the Quintessential element]
Each chapter is illustrated with wonderful stories. An example: JFK's 1961 speech to Congress in which he challenged the US: "I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the Moon and returning him safely to the Earth." The result of this challenge was not to start putting people in rockets and sending them to the Moon. It was much simpler steps that built upon previous learnings. Their example is the Ranger program, in which NASA tried 6 times to just hit the Moon, and failed before succeeding in the seventh attempt to crash Ranger 7 into the moon. Learning in each attempt, solving bigger more complex problems by iteration.
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).
The post Why Take A 3-Day Certified Scrum Master (CSM) Class? appeared first on blogs.collab.net.
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.
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
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
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,
that was a bad business model. I told Ken, that was a bad business model.
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
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
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
talk about testing.
But if you go back to [inaudible 00:10:51] book, the production
system, he talks about this thing called autonomation. And he means
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
country or the world. And he was telling me about this. And he tied that
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.
Al: So think about this. So one of the biggest problems people have with
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.
Al: Yeah, well you see the other thing about this is then, if you think
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
Interviewer: I will look it up, I will look it up on Amazon post it to
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
read it carefully.
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
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
going to talk about this. I am talking about it inside the community and
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
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]
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 developing an organization’s “discovery muscle” as well as its “delivery muscle.”  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 innovation.” 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 , explicitly makes the case for equally balancing your commitment to these key activities. 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 otherwise 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.
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 vision 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.
Discovery is a team sport, not a spectator sport. Your discovery 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 perspectives 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 conventional wisdom may help you discover something that gives you a competitive advantage.
Holistic Discovery Practices
Discovery engages the partners in learning and possibilities—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 provider, the partners quickly identified “obvious” users such as health care members and health care providers (e.g., physicians). 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 possibilities 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 product’s possibilities and decide what to deliver. You explore options for all 7 Product Dimensions. As you evaluate the benefits 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 discovery and the more focused thinking of confirmation and delivery.
Discovery is the rich interplay of creativity, new or expansive 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 practices 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, improvisation, 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 explode 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 possibilities and yield serious outcomes. You can also use sketching, brain writing, affinity mapping, or card sorting activities. Techniques 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 visual thinking.
Figure 5: You can use various discovery tools and techniques according to the planning view.
Calibrate Your Discovery
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 definition 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, possibly a few weeks to a month), your discovery muscle is toned and controlled. Your discovery is framed within a clearly defined 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 iteration: 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 requirements in sufficient detail to enable immediate development and potential delivery.
Training Your Discovery Muscle
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 uncomfortable, 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 business through different eyes. You will develop skills in discovery and innovation, building muscle memory so that discovery becomes 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 discoveries 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, employs 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 acquainted 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 conversations 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, opportunities 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 opportunities.
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 frequent exercise, their discovery muscle becomes stronger and more limber and works smoothly in tandem with their delivery muscle.
Want to learn more? Contact us:
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:
- 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.
- 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.
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.
To demonstrate my point, I’d like to share this case study…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.
The Scaled Agile Framework web site thoroughly describes the SAFe model. SAFe defines three levels for scaling an Agile organization:
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
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.
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
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.
- Reaching consensus on portfolio priorities was difficult and time-consuming. The Business Value Game or Buy a Feature would make it more effective.
- 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.
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.
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.
Finally, take personal responsibility for helping your organization learn and grow. Use your network to help you do this. In one organization I worked with I created a monthly forum where well-known agile thought leaders were invited in to present new ideas to the organization on a wide range of topics. I did this as a hosted web conference that was recorded and archived for those unable to join live. Providing this access to thought leadership was inexpensive and helped others immensely. It also helped the presenters by providing additional exposure and even gained a few of them business engagements at the company. Don’t be shy in reaching out to these individuals as most are approachable, personable, and eager to help. You simply need to ask.
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.
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.
Limbic brains feel value, but can’t necessarily quantify it. This is where you start – with agile, with our event and with VersionOne. You start with feeling something about your product, your service, your partnership and, most importantly, with your own motivations.
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.
“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:
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.”
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.”
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 value, hence 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.
Agile Made Easier
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.
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.
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:
- InfoQ: http://www.infoq.com/minibooks/agile-retrospectives-value
- Leanpub: http://leanpub.com/gettingvalueoutofagileretrospectives
About the Author
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.
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 question “Is Your Business Model is a Good Fit for Agile“