Good morning and thank you all for joining
us today. This is our first webinar for the Agile/Lean CoP and we are excited to present
to you. I would like to thank digital go — especially Andrea. Allen for helping us get set up. The
first of what we hope to be a series of webinars dedicated to agile within the government context.
Today we’re going to talk at a high level about agile. And drill and a little bit on
how during this transformation which we are in the early stages of — what types of personalities
and resistance you might face whenever you are tasked with implementing it or making
the transition over to agile. We will go ahead and jump right in. I will get a very brief
introduction for agile 101. And we will jump over into introducing our speaker Bill Bradley.
Will talk more about his credentials and some experience — you will gain some insight into
the lessons he has learned. And the generous stories he will share with you about his experiences
going through implementing agile and large changes that have been significant in terms
of the paradigms — for example open source as well is agile.
>>Here is a primer — some people still get confused as to what the value of agile is.
I really wanted to knock this out real fast and clear the air. Is focused on what the
punchline of agile is — the underlying foundational value we will be focusing on. Not only in
the webinar but hopefully also through the continued series. Essentially we’re talking
about a paradigm shift from the traditional sense is a very plan oriented means of product
development. The waterfall traditional method has this conception — the interpretation
of these steps is different in different organizations — essentially we’re talking about you compile
a long list of requirements. You design what that looks like in terms of the technical
product limitation — or even a service implementation. Then you built that. After some time you’re
spending all this time doing all of this in implementing the plan. Once you build it you
have delivered the first time spending all that time and resources before you make the
first delivery. The problem with this paradigm is that what happens if the customer feedback
is back? Mike Tyson said it’s infinitely everyone has a plan until they are punched in the face.
What essentially we are faced with when we are punched in the face, is we basically run
out of time and resources. There is not much we can do. We had been knocked out. Agile
takes an embrace of that punched in the face — so to speak, and incorporates it as a given
as a part of product development workflow. Part of the lifecycle. Let’s say we have the
same amount of time — what we will do is take a piece of that time. Plan upfront to
take a portion of that time. This week go through the same process requirements. We
don’t call them these things — but conceptually it is the same thing. We put together a backlog
of features and figure out how it will be implemented, test them and wants to the customer.
We’re going to the same process but in a shorter time span. If we go through this process and
we expend all of our resources in this bit of time, what we do is if we get the feedback
and it is negative — typically no matter what we’re planning for the customer when
we engage them directly and releasing this into the wild, we will have some unpredictable
results. So what we do in agile is what we call a picnic. Once we get that feedback what
ever it is positive or negative we incorporate it in go on and spend the rest of our time
learning. This is also institutional or team learning.
>>I like the way Steve then local talks about it — we throw the term around a little bit.
It can scare people. Really what we’re talking about is exactly that. Going from it the type
of failure where we do this large plan and we deliver and we learn recently at this point,
in the waterfall, once you make that delivery waterfall method we are basically going to
be forced to ask for more time and money. How do we break that into smaller pieces and
deliver it more frequently and fail and learn rather than they’ll be?
>>When nuance I want to unpack for us before we jump into the presentation. The conversation
about the difference between lean and agile. We’re talking specifically about Lane in this
context we are talking about a meal Lane. It has been around a long time. Extends from
the manufacturing industry. We’re talking specifically in this case about the lean startup
methodology. The new waves rippled is causing in a number of different organizations institutional
context — such as Lane US or Lane government. The difference between lean and agile is really
a level. Agile is a product level — learning and refinement, customer feedback driven refinement.
Oriented methodology at the product level. We are improving the product over time by
exposing that the back and making it more — deliver more value for the same amount
of time and resources. We do that same thing at the business level not just with features,
as we would do in IT projects, but what are the overhead of the support you might or might
not need that really time everything in the business, the employees, human resources,
the tools, logistical, supply chains — suppliers and so on. Time everything directly to a customer
value. That philosophy really is that the lean level is a methodological limitation.
>>This is a great strategy. The people that get it are really excited about it. I think
it is warranted. We are powered by that fuel — that excitement. No matter how good the
strategy is, culturally speaking, agile — we will take an agile approach of the webinars.
We really appreciate other feedback and the input we get from our viewers. Our community
of practice was asked early to provide some insight into the composition and really appreciate
the responses we got. We’re hoping we can continue that type of engagement as we continue
developing our webinars. We did a survey of our users early on and we found that in line
with our experiences, we are embryonic in terms of agile and government. Considering
the timelines of government. 1 the 2 years of being the lion share of people’s experience
in the government context. That is brand-new. And we’re going to be facing this kind of
transitional growing pains as we move through and we start to push that — that Bell curve
towards a decade or however long it takes to make the full transition. Agile is a status
quo in the private sector — only been around for about 15 years so relatively new. Technologically
speaking we are accelerating as a culture and society and we are hoping we can — to
this chain of communication and accelerate the transition so it is less painful.
>>Agile manifesto was written in 2001.>>With that background — foundation I would
like to pass it to Bill Brantley was been doing this a long time. He has been doing
this through a number of different context both governmental and private sector. Also
in a startup. He not only advocates — he is not only an early adopter but he has had
experience with different types of cultures. I think he’s going to bring all of that experience
here to bear — and share that knowledge with us.
>>With that I will hand it over to Bill.>>So Bill I don’t know if you’re still on
mute but go ahead and unmmute yourself.>>Hello Bill looks like you are unmuted — you
can go ahead and talk.>>Okay is that working?
>>Yes>>Is your microphone not working?
>>There you go>>Sorry about that. I see what happened my
court got wrapped around my chair. Learning things everyday. Thanks so much for the great
introduction. Go ahead to the next slide. To a lot of what I will talk about is like
Logan said I will have been in this for a while. A lot of this is learned the hard way.
You will learn from my mistakes as I tell my students. Learn from my mistakes because
I make lots of them. The biggest thing I want you to get out of the presentation — I’m
going to go with a major point about the change in models which is what underlines the culture.
Everyone has a model and how they perceive the world and work with the world. We also
have shared mental models that under — the foundation of our culture and our organizations.
I have this great quote from a book lean change management — an excellent read. I like the
way the authors summarize what was going on. Essentially what we have is the old mental
model of plan driven where we sit down with the waterfall traditional method and we make
our list of requirements to figure out how to get from a to B. We have a solution in
mind. All we have to do is get our requirements and figure out how we will fulfill those requirements
and produced a solution. It is all ready to go. After that people — I am exaggerating.
People stop thinking and start following the plan and we have a lot of faith in the plan.
That is a plan driven mental model. What we’re doing with agile is changing to a new mental
model — a feedback driven mental model. Instead of having a complete plan in place we will
have a list of requirements — we will have a plan their and we will start working. And
then we will build something, it will type. Then we will go to our customer. We will show
it to the customer and we get feedback. There we go back to work with the plan and list
of requirements. You’re going from point a and you are not really going to point B or
C — the journey can change. Your original plan can be very different from where you
started. That is the big point we are making today. When you do cultural change you’re
going to have resistance of change of course. You might think — see this chart on stages
of grief. Because people are losing something. People have a very big aversion to loss. They
hate lost more than they appreciate gain something. So we show this to you to show you the different
stages here. I’m going to concentrate on the bargaining. One thing I want you to note is
how the emotional response goals from passive to active. One of the things I ran into early
on is that anger and acceptance and bargaining are very active emotional responses that is
easy to see and work with. The thing is — I was forgetting about where the passive emotional
response was like depression. They are not reacting badly. Not getting anyone angry at
me so things might might be going pretty well. Not in all cases. We had the passive aggressive
— strategies. Sometimes with when you don’t see overt resistance to change you still want
to watch out for that. Make sure that people are not just in denial and we’re just going
to tonight agile exists. Or do whatever you want to I don’t care anymore. Not to figure
out where they are in that and figure out where you are. I have experienced this myself
when I worked on agile projects I have been on the cycle myself. Because as an agile person
I want to help solve people’s problems, I think I have a great solution for them. It
takes a real tough personality or a tough skin to take that critical customer’s feedback
and say — that solution just not work for you, but I appreciate your feedback.
>>What we have a lot of times we talk about — we have bargaining. Essentially people
say yes we like agile and the benefits, why don’t we just combine the 2. We have our waterfall
and agile. Again — in some cases you can actually combine those and there are some
hybrid methods that work for specific projects. In a lot of cases what you run into is that
we’re going to do agile but we’re going to [Indiscernible]. We’re really doing waterfall
underneath. That is what we are working with and that is what we’re falling back on. In
this case we want to talk about the different personas and how they bargain with you and
the trapped you can fall into. We have our most aggressive persona — all of these can
be aggressive or passive. Most of the time the perfectionists are pretty aggressive.
The perfectionists here — and I admit I am one of them — people that are perfectionists
like the clarity of the waterfall simulates. You have a list of requirements, we know where
we are going and we have a schedule and benefit and what everyone will do. Just follow the
plan and keep going. A lot of time the perfectionists will step in and they say I am the customer
and rather than being the voice I know what the customers want and they need. You don’t
need to talk to anyone else because I know. The feedback stub — just follow my list of
requirements and you’ll be fine. You will hear this. Everything is in the plan — look
at the plan. This is the best way forward. This whole thing about — no one wants to
[Indiscernible]. We don’t want a project that is halfway done and you keep coming with these
different prototypes. We know what we want, let’s go. We’re trying to get [Indiscernible]
with them you need to convince them that done is better than perfect. A perfect solution
two years from now might not be good for them. Don’t let perfect be the enemy is what got
me into trouble. To go to our story here — around about 2000 or so, I was working for a company
called technology consulting international — the technology consulting company. I was
with a task or on a project from national petroleum. They had about 28 to 29 Lotus notes
applications. I don’t know if you all have seen those Lotus Notes — they had 28 or not
29 of these applications. I was tasked to take it of these applications and turn them
into ASP applications. This was before so it gives you an idea of how long ago this
was. They were going to move to a Microsoft platform and they wanted everything in ASP.
The plan was very simple — take these applications out of Lotus Notes and make them look exactly
like they would in Lotus Notes but do it in ASP. Simple plan — we knew what we were going
to do — I went with it. I had 10 successful projects in a row with that. 10 successful
applications and the client was aesthetic. It was going well and we were on schedule
and on budget. So I came to my 11th application. The 11th application was a Lotus Notes type
video library kind of thing. Back when we had VCRs and VHS cassettes. These were for
the plant management. In the plant boxes in such. Just HR topics and things they can watch
like how to manage the workforce, and work accidents. This application basically just
listed these 27 or 30 videotapes. I thought — I am following the plan, I am doing a great
job in the customer likes me and I know what the customer wants. I am the perfectionists
here. So I built that application in ASP. And I built it under schedule by the way.
It was perfect. It was those 30 — is sort of those videotapes perfectly.
>>It was a great application. I sent it on. Two days later, I get a request to come see
one of the partners. And he shows me an email from the client. The client is jumping mad
because what they paid for this application — was like what the other applications, $10,000
or $20,000. What they paid for this they basically said we could have done this easier and cheaper
in Excel spreadsheet. So what the heck were you trying to do to us? I’m going — follow
the plan and it was perfect. This is at the point where it might have been perfect, according
to the plant but it was not good according to the customer’s perspective. So again I
bring that up to bring — sometimes it is you the agile person that might be in one
of those grief stages rather than the customer. Is a great way to learn from my mistake.
>>Our next one is the controller. And this is more aggressive — sometimes it can be
passive. You will see more active resistance. They don’t want to lose control — they don’t
want to go off the rails. They want to make sure things are going as planned and they
want to make sure you are doing what they say you are going. They really want you to
follow that path and they are having laid out. We have the plan and my list of requirements
— just execute the plan. The famous phrase they like to say is you fail to plan your
plan to fail. They had the solution that the waterfall list of requirements, the plan gives
some good conclude — good control. That is how they handle the project. If you don’t
have a complete list of requirements you don’t know where you are going you don’t really
know this when you don’t have control of the project that you are out of control and we
don’t know what you’re going. The story on that one — I was working for start
up. And we did a lot of work with real estate agents — prebuilt websites for them. I was
building a coding language — is like PHP. We were building all of these real estate
websites. At the time real estate agents have a very competitive market. They live and die
by their marketing. We had real estate agents come to us and saying we want a great website
that really markets me and we wanted to look amazing. I want to make it better than my
competitors. Does pretty much the list of requirements. We had some technical things
— we want this kind of color scheme. But really I want something that looks amazing.
>>Well what happened is that they would walk off and they would save make something amazing.
And we started doing that and we were naïve about this. Were building something kind of
amazing. They will come back and get the feedback they did not like it. And they got all mad
— this looks awful, do it again. It was frustrating for me, frustrating for the customer — we
have the communication. We thought they were telling us what they wanted and we thought
we understood that we did really did not. Taking something I learned back when I was
a [Indiscernible] in the late 90s, I was trained and wrapped Jack — it is like a lame technology.’s
stance for rapid application development joint application development. The entire idea was
you were in the room with the client in your building wireframes, building the websites.
This is a 1995 and 1999 kind of website. And you would be in there with a wireframe in
building it out for them. Getting their feedback. So that you can build a much better website
for them that was more responsive to their needs. So what I did was I convinced some
of the real estate agents, please let me give you a call every other day in the morning.
I won’t take more than 15 minutes. I got a place on the web you can see your website
and nobody else can see it. I want you to look at it until me what you think. I want
to get your feedback. I promise you your website will come back faster, and it will be more
of what you want. It will be more of what you like to see in your website. The whole
idea here is — you want to hit or stop this thing called a [Indiscernible]. The client
knew what they wanted. But you did not know because it is hard for them to communicate
it to you. This is why the check ends in the wireframes and prototyping and all of this
is so important. And hope to get out of that course of knowledge. Opium were used to work
we used to have a thing called the show me a rock game. You will go to someone with a
rock and they would say that is not the kind of rock I want — you would go get another
one is sure to them. But that is the way it was. You did not know what they were looking
for in a rock and you just Showing them rocks and he got frustrating for everybody.
>>That is the whole idea behind controllers and why you need to really convinced him — you
need to check and more often. Another persona is the old guard — they are more passive.
They can be active when they feel threatened but they are more passive. These are the people
that have been there for a while and they have seen a lot of things. Their experience
is valuable. I like to listen to them and listen to their comments. And understand their
perspective but sometimes they don’t like the term experiment. They don’t like the fail
fast. We felt before it was awful and people got hurt — we don’t want to do that. We don’t
have time to waste on playing around on these prototypes in such. Why don’t we spend more
time working on the list of requirements and planning it out and make sure we get a good
solution the first time. That is an interesting — it is a good point. But in some cases like
with some [Indiscernible] you might not know exactly what you want. There is also that
illusion that if I have a list of requirements and have a solution in place is going to be
perfect from time on. I don’t need to work on changes in the environment or changes in
the agency or anything like that. The whole idea is to avoid the risk. They are very scared
of risk and loss. What you need to do is show them how risk is reduced by agile. We call
it positive or negative risk. The idea that waterfall is a huge plan — there is a high
potential for deviation. That is why we need to do it in cycles and we need to iterate.
Sometimes you have to bring in some people that were not there before when the last major
disaster happen or whatever. And they come in with a fresh perspective and they don’t
have the stigma of the past failure. They can come and, show us some things — we’re
doing a pilot and convinced the old guard — in the past it may have felt that now things
are different. We have newer things that we can work with. To the story on that was when
I was at OPM, I was detailed in open government group. One of the things we worked on with
the open group was increasing collaboration and community internally in the agency. So
being an open source developer and playing with applications like Word press — alfresco
and all of these, I was also equally inspired by Gray Brooks and his work over at FCC. I
love the way they had a fixed where you can build your own personalize webpages. You had
a page — think about your mobile phone are compelled a nap down and make your own personal
start page. You could do this thing with — at the time. You can pull in different applications
and different blogs and build your own personal work page. I thought that would make an amazing
Internet to people. You can build your own personalize webpages and if you had to go
on vacation you had all of these blocks you can send to your neighbor and the could work
for you or do things while you were out.>>I work with alfresco and solar to build
a nice minimal viable prototype — 666 I think solar was just coming out. Just showing this.
We have a viable prototype and now showing it around the agencies. Two different department
heads and CIOs. First thing I ran into was — isn’t this just like SharePoint? Why don’t
we just use SharePoint? Because we were µ-based environment — it wasn’t like SharePoint.
Would’ve required a large server and this was a smaller leaner more open solution. That
we could really dig into it to make it the way we wanted to. That is the way I try to
argue it. I had a lot of — I was going up and down the [Indiscernible] recycle. Just
when I considered a half when — basically I got the idea that open source is not bad.
We can use it and we could help build things better. They went with a different type of
open source application or platform. I think it was in Bracco which is Microsoft-based.
We got open source into the agency and got people thinking it is not just a security
threat — it can be done and work the way we want. I think my perfect solution which
I was in love with my baby, I got the old guard to relive a little bit and look at it
at a different way and change the culture a bit. About bringing an open-source. We had
a half day and we had Gray Brooks as our keynote speaker. It was a great conference and we
had a whole line on security. I think it helped change the minds. Sometimes when you’re doing
agile and lean you might have to accept not the perfect solution you had in mind when
you are listening to the customer in working with what their cost — comfortable with.
One thing that helped is the idea of social proof. One of our CIOs — I saw him at the
conference. We went to a CIO Council meeting and there was a — I think it is a WordPress
— is that now they are using it so I guess it is not all that bad. Sometimes you have
to find other people were doing it. Probably our most passive persona is the last in line
people. These are people that — they are not familiar with the technology, not really
convinced about agile and it will take a lot of convincing. The people that if you go to
a restaurant there looking at the length of the line — better the line — the longer
the line the better the restaurant. If you are familiar with Geoffrey Moore’s diffusion
of innovations theory, these are your late adopters. What is going on here is who else
is doing this was Mac why should we be first? The case here — don’t just dismiss them.
They might have good ideas. Some good points. Sometimes you need to answer the fears they
have and the loss aversion they have cultural change. You are trying to move this — is
easy to stay with the familiar and such, but help them — don’t belittle them but help
them.>>When I was at OPM — there was 2008 and
I started pay systems. One thing I noticed is we had a large amount of documents we would
work with in creating the pay tables and other things were working with concerning pay and
leave and all of those other issues. I came in and I was at the time playing around with
media wiki which is the engine that runs Wikipedia. I thought why don’t we use a wiki instead
of taking these documents and emailing them around and doing track changes and word. And
why don’t we use a wiki because we have the version control built and — we can easily
search things and see what people change stuff. Just make more sense. You have the PD out
there which is social proof. I did some demonstrations about how wiki works and how it will work
with our documents. I used some social proof and other agencies –.
Large federal governments were doing things.
What I did — I did the demo and I got a lot of good feedback about that. One group that
did not like it was the CIOs office. They were concerned about giving the users that
much control over creating content. And sharing documents like that. There were could — security
concerns. We have a wiki about a couple years later but it had to go through a vetting process.
That take sometimes. Sometimes with agile you want to the move fast but the culture
will slow you down. We have were pressed — on these guys are building themselves out there
I will talk about we could use WordPress for content management system to help us with
publishing the pay tables and help us with publishing pay letters and such. That didn’t
go anywhere because people like having the document they could print out and look at.
It was cultural. WordPress where is that going? It was pretty well-established at the time.
And we had — with the KM as. And just again when I first put together a proposal, and
how much it will cost and how we would have to put it into the agency, there was some
concern over the cost which was way too low. That is open-source and that is how you can
work with this. Is not going to be your big piece of iron — we have a whole group that
can help us with this and can borrow from other agencies. The idea is show them some
social proof but realize they are the last one in line and they really have to see that
shown and proven. Does go to some key takeaways.>>And again this is when I tell my students
— I know in an hour-long lecture you are not going to remember everything. I like to
boil it down to what is the best 5 minutes at this point you can get from this. Is take
a look at our verse one. Understand the mental models. How do they perceive the world? Why?
Help them change that model. The big model change you have to do is go from plan driven
to feedback driven. Planning. Did you have to help the people that have the old guard
mentality or the last in line mentality. Understand how they perceive. Helped him work with those
models. Be aware that when you’re working with the models you have to work with the
loss aversion. Have been all kinds of psychological experiments about that. People are four times
more likely to fear loss than two enjoy a gain. So people are much more scared about
losing things — losing control, losing certainty. All of the different things that can, where
you have a solution of I am in control, I know where the plan is going — with the plan
driven into model. With the feedback model we have a plan and we’re going to take this
journey together. Some people are scared of the journey. Also be aware of the locations.
This is another one of my mistakes. I got and lean agile overall back — they like the
whole idea of doing things. And I was in college I was a convert to Tom peters works. I will
talk to people about these great ideas and good things. People told me this to my face.
I was acting like they were stupid. Why are you doing this this way there is a better
way let’s do it this way. If not you are in it idiot. Sometimes I get that will talk to
other people. If we don’t do it this way you are an idiot or you are not using this — be
aware of the implications when you communicate with people and try to help them along the
journey. Help them change their mental model or — only they can change their mental model
to help them with the change. Don’t and so people — that is the biggest way to a shutdown.
Eat your own dog food. Agile is not a panacea — try a hybrid approach. Make it your own.
Don’t just go to another agency and say they are doing it and it looks cool let’s just
copy it. Make it your own, customize it. Always consider what you are doing, question what
you’re doing and we listen to the customer. Remember my first story — the biggest mistake
is I thought I was the customer. Customers will surprise you. So you have to eat your
own dog food –>>Beware of the agile myths. When I talk
to people and they get excited — they think we know how to document things anymore. There
is agile documentation. There is the backlog, the burned down charts. There are different
ways of keeping track of what is the customer wanting, where are we on this journey and
what are we supposed to do next and are we meeting the customer’s needs. You don’t need
a bunch of it like you which traditional or waterfall, but you need something everyone
can agree on. Honestly I tell people get it in writing because you trust people verbal
memories is going to be a lot of trouble. Also some people think there is no risk and
agile. Just existing as a risk anymore. Physically in agile there is risk — you have less risk
and you to work with risk because sometimes it is just change and we welcome change. Don’t
just think we have agile and we’re doing it right and we don’t have to worry about risk.
They can fail on a large scale — do your due diligence and make sure you are looking
at your wrist. The biggest thing about agile it is about learning. Is like Logan talked
about. Institutional learning, team learning — yelling fast and learning from your failure.
A lot of people don’t learn from their failures. Also — beware of agile theater. Some people
get really excited about this. They get a room and they get some burned down charts
and they do retrospectives and all the motions. Then they get — fall into this agile Orthodox.
If you are not doing it this way you are not doing agile. If you’re not having the retrospectives
in this formula you are not doing agile. The whole point of agile is simply to learn from
your customers and its rate keep learning. If you can learn better without retrospectives
that is fine. If you can learn better from a different way that is fine. With agile is
really easy and is popular right now I’m seeing some people getting in there about agile theater.
And the whole idea is are they really listening to the customer? Are very incorporating the
customer’s feedback into what they are doing? And does the customer feedlot — feel like
they are involved with the production of the process. Keep questioning what you do. Don’t
just be satisfied. Let me put in here real quick — if you are an agile person you will
have a paradox Eagle. What I mean by that is you have to have enough in of an eagle
you are sure about what you are doing — but you know you’re going to get a solution that
is going to meet the customer’s needs and you have to have at least. At the same time,
you have to have an ego that is very open to what the customer says and sometimes take
harsh criticism. But you have to take that and don’t get upset or defensive. Say thank
you for that — that helps me and it helps meet me your needs and build the product you
want. So with that, if you have some agile success stories or a good failure story or
whatever, please share those. We love to hear that. That is the best way to learn. I would
love to hear your stories. By no means am I a perfect agile person. That is the great
thing about agile — you are always working to building yourself better.
>>With that I will turn it back over to Logan.>>This has been an incredible. I love hearing
the stories. Actually I have heard a couple of them before because we of course had to
do a dry run. I want to talk about that social proof. You mentioned how social proofing — or
exposing the stakeholder. I think you mentioned something before about that being an a CIO
Council?>>We had a CIO at OPM. I was showing him
the demo and he was not sure of it. When they went to the Council and they saw how it was
working for them, they thought my fellow CIO people seem to like it be okay with it. Maybe
it is something I should look into.>>I also like how you talk about yourself
is the perfection is persona. I think we all fall into one or more of these personas at
various times and various stages of our experience based on how much experience we help with
something. I think we can fall into any number of these personas along the spectrum of active
and passive resistance to change. Change is hard. It is to some degree painful. I think
it is important for us to ask ourselves what persona we are. Whenever you thought about
your transition to agile — was it experience? I think it sounds to me and Bill’s case, it
was experience. Maybe you can verify. What got you to come over to the agile side of
the waterfall?>>The biggest reason why is because — I
worked in state government and local government and startups — there was a better way of
doing things. I got turned on to this when I was in college — undergraduate. I had a
really good class or management theory. We got introduced to Tom peters. White people
doing this more — why aren’t people doing this more? It is more efficient. You start
thinking — you see all of these big failures. This was back in the late 80s. And you start
seeing some of these companies coming up. You so Apple and Microsoft — Apple especially.
Apple was just taking off back in the late 80s. For a long time people — Apple was on
the ropes. When Steve jobs came back and help them refocus — honestly, most people did
not think Apple was going to survive outside of the 90s. All of a sudden they are starting
to focus and do these things and they are back on top. To get them nowadays.
>>It was a really expensive product for a lot of people. When I got my first computer
that was part of the decision-making. So yes — we have a couple of questions that have
rolled in. Feel free to add your questions. We have a few more minutes and we can hash
out some questions. We’re going to close this up — I know this is a lot to digest. I would
like to ask one final question as a panel facilitator. I will get to a couple of questions
we have received. Feel free to ask them their. We will have opportunities to the publication
process — you can send this to the YouTube. So they are more meaningful and more in-depth
conversations. We will be distributing the actual presentation through Google Docs so
people can provide comments to the slides, have their questions in context within each
slide. Don’t feel like this is your last opportunity to engage. This is the beginning of a conversation
not the end. You will also be asked to fill out an evaluation form. So please stick around
until that out if you get that. We really appreciate the feedback.
>>One more question for me and then I will jump into the questions from the audience.
From the perfection is prospective — we can’t all represent all personas — to give us one
example, what are some of the other personas or which other particular persona are the
most perfect — difficult to emphasize — empathize with or collaborate with tourists change?
>>I think with me it is the last in line people. It is this — I am one of the — I’m
an early adopter. I like to get things early. I get fascinated by the things I adopt. Just
to give you a reason example I just got into the media framework. Amazing stuff you can
do with it. I am excited.>>Meteor is awesome.
>>Angular broke my brain a little bit. I’m still trying to work with it. But I love meteor.
Some people are like how proven is it? Where is the documentation? I’m like we can work
with it as we go along. So I’m like a perfectionist but also at an early adopter. These last in
line people that want more proof — how much more proof do you need? Here is what you can
do with it. That is to me sometimes — I realize I have to listen to them — I have gotten
stuck — when I was at [Indiscernible] we went with the — language which you don’t
see anymore. We chose that over PHP. Where is PHP right now? That is the thing and technology.
You have to — you have to choose one path and you’re going down it and it cuts off the
other paths for you. With early adopters like myself that are perfectionist, we tend to
run down the path sometimes without thinking about
the implications. That is one thing I try
to watch myself with.>>Fantastic —
>>Another question from the audience — can you talk a little bit about, we had a thread
on this on the listserv and I will refresh it. I think this is a really great question
that comes up a lot. Can you talk about how agile might be applied to other than software
projects — maybe hardware projects or services — maybe can talk about your experience with
that?>>That is a great question because I am trying
to do that myself. When I was working at OPM — I’m an accidental HR person. I got into
HR — I do college teaching and I like the training aspect. I have been bringing project
management training into trainers to help them with project management projects — the
training projects. I’m finding that nowadays the way people learn and the need for companies
to keep companies and the agencies to increase the skills of the workforce, you can’t just
do an old-fashioned training project for you spent all this time building up a list of
requirements and your course and all of that,. There is a model in there we use called analyze,
design, develop, implement and execute and that can take a long time. So you are saying
some other methods coming out there that are more agile like Sam which is an adaptive model.
You get some feedback and you keep iterating through. Of the stages you are iterating through.
One of the things I like is rapid e-learning we were trying to get some online learning
quickly and you are using agile and lean methods to do that. Do you get a course out there
and you get some feedback on it and you keep fixing the course in building the course according
to what the students need and such. One of the exciting things — this is way off from
the software world and hardware world coal we call it personalized learning environments.
Where you help people — you curate the content. There is so much content out there. You are
like the guide on the side — the sage on the stage. Now you are the guide on the side
and you help people on a journey through learning. We are using agile and lean right there. We
look at what the students are doing, the metrics and what they are looking at and learning
and where they need to fill in gaps and we built into that. That is one area I am interested
in.>>That is a great example. — We’re also
trying to use agile to inform our actual community development. I think that agile — it might
not be a panacea — but I believe it to be a teacher that is quite versatile. In is efficacies.
But maybe I am biased. I have gone full throttle with this agile. I have totally drank the
Kool-Aid. There is some really interesting things that have been shared in listserv.
I will refresh the conversation. Agile family-planning — or having family meetings and improving
your family dynamic overtime by being agile. And responsive to family members. There is
a request here from the audience — I resonate with this request. Not just successes — ethically
focus a lot on failure as well. We learn and agile — we embrace the lessons we learned
from that failure and really as long as we can take inside you can convert into learning
and therefore — and through that success in the end, we want your failure stories as
well. If you have something you feel like you have learned a very valuable lesson in
terms of transformation. Agile success or failure stories that we can learn from, please
email us and we can find a way to synthesize that and share it to the community.
>>Another question — I think this is a good one. And the federal government context we
think of this — think of funding in terms of fiscal year. Managers and technical support,
how much money they need — for the entire year. How does agile, how do we reconcile
agile with this fiscal year cadence that is almost really insurmountable? How do we deal
with that? How do we reconcile the 2 paradigms?>>I’m not an expert but I was at an event
— last year at GSA and I was the moderator there. We had a gentleman that was an expert,
a master and he talked about that and addressed how you work with some agencies to structure
their contact — contracts so they could work with that annual fiscal budgeting. And pay
for the results copy services — I’m not sure how he did it. There are ways to do that.
You can be more agile in procurement. One audience member — I like the comment they
made. With agile in government we need agile budget. There are ways to do that that agencies
are becoming more open to. This process was you’re going to pay us for our services which
would be agile services. You expect to see certain goals — certain number of prototypes
come and that would have certain features and that would fulfill the budgeting. Basically
we will go on next year and based on those products — prototypes. It was an interesting
way. I really wish I knew the details. Hopefully he is on the list and can tell us more details
about how he worked that.>>We can unpack that a little more later.
How do we reconcile the fiscal year funding situation with an agile approach? I have actually
heard of people just saying — this is how much money we have used. We have this sort
of pre-existing condition where we seek as much funding we got last year and find a way
to spend it. Even within that framework — you have a certain amount of developer hours you
can contribute which is nice about agile. You are going to accomplish something with
any given amount of money and time. It will deliver some value because it is not like
you are determining what the project scope should be in there by determining what the
budget should be. You have a certain budget and you will get something done that is valuable
to the customer within that budget and time and you do that by breaking these large projects
into small bits. And constantly getting customer feedback.
>>I have a poster on my wall — it is a viable product. What I like about it is that shows
you at the top — you have your building a car. The first part is you have 1 will — than
two wheels connected together. And you have a bunch of unhappy faces on top of it. The
real way to build a viable products — you start off with a skateboard then you have
a scooter than a bicycle, then a motorbike and then a. The whole point is when you do
your viable product correctly and you plan that, your customer is going to get value
out of every prototype that goes along. It might not be the eventual solution they end
up with but it is a solution they can work with.
>>I seen a similar diagram — would you rather have half a sailboat or sell bulk without
a sale? So yes — you want to deliver value at every point. You can do that no matter
how much money you have. Break that up. I think there is another way of saying customer
development — so Google customer development is that is interesting to you.
>>Along the lines — we have another question. Is there a finish line with agile? It seems
like you can just start with an MVP and have a never ending list of changes. Is agile really
a way to go from revolutionary approach — create something, be delivered and then with it — that
kind of finite approach to product development where things are determined or perceived or
supposed to be definite and a clear and deliver against a very specific plan. From that paradigm
moving over to a evolutionary. Things that constantly are changing and evolving over
time.>>That is a great question — I’ve seen this
before where you have the agile John. The team is doing agile but they keep tinkering
with the product — when do I actually get something and when are we finished? It really
depends on conversation you have with the customer. And what they are looking for ultimately.
What is their need and what is going to satisfy their need? What is the ultimate solution
to them? You might not reach the ultimate solution — but it might not apply in your
so. Going back to the customer — this is what we have for you so far. Does this meet
your need? Also asked do we need to do anymore? Some customers I have heard about — they
will say okay after 10 sprints we should be fine. They try to do it that way. I don’t
know what that is effective or not but it helps with the budgeting piece. Another one
— don’t go for perfect. Like I was trying to. Where I go for the perfect solution. Go
for the good enough. Does this meet the customer’s needs? Are they happy with it? Does it fulfill
the bigger goal of the customer meeting what they need to do? Is this good enough to meet
what you need? Because next year things will change Budgeting will change — new issues
will come up. That great solution last year might be the thing holding you back from this
year solution.>>That is great. I have heard this — in
other similar vein of thought where — you are not assuming — instead of packaging these
products as definite things and is evolutionary approach, how do you deliver value consistently
— it is always a good enough because you can’t expect that you are going to get everything
right. That puts us in a position that we’re going to get the stop exactly right. Even
if we did get it right and we launched this thing out two years from where we started
the plan, two years is a completely different ballgame technologically speaking these days.
Who would have thought — there was a bunch of speculation of whether the iPad would be
an interesting thing for people. Now we have and I watch — what is the spectrum of technology
and how fast is that changing? We really have to address that. I think that is the nice
thing about agile. It allows us to be good enough, get out there and prove value as we
think this is a good segue into a question
here. What is the difference between iterate of an agile? I see them as hand in hand.
>>Iterative — you can have traditional projects. Have something we have called phase gate.
Will you build the product — and you iterate. Were working a way towards your solution.
I think the biggest difference here with the agile and iterative — with the agile I am
going back to the customer and showing them what I am doing. With the agile it is more
like I am pulling them in, we’re joined at the help and we are — they are helping reshape
it. With iterative I know I have a solution in mind, I am just iterating my way towards
it. With agile, I might pick it — I might start off with this is my solution but that
is not working so let’s pick it go to another solution. You are working your way towards
a destination that you know. With agile you are probably working towards a destination
that will change on you. That is how I see the difference.
>>That is fantastic. We’re just about out of time. We have one more question. We won’t
really have time to answer it. In the last minute basically I’m going to address this
by saying, standby we have —
in terms of iterating closer and closer with what actually users need is it really just
user experience project management? We will be doing another webinar on agile UX. I hope
will have a chance to address some of that stuff. In my mind, the product owner product
— project manager of this documentation is going to move from requirements to really
customer and user experience feedback type of qualitative and quantitative documentation.
That is really where the documentation is going to happen. And agile. We are out of
time. And you all so much for joining us. Join the conversation and let’s continue with
this. There will be — the slides will be available. Please fill out the evaluation
form. Bill do you want to close this out?>>Thank you all for having the inaugural
conference. I appreciate the opportunity to talk about agile. I hope people learn from
this. I look forward to the comments on the listserv.