Got
Individual Obstinance – The Idea
Agile in a Flash by Jeff Langr and Tim Ottinger (card #12)
> Personal bubble: “I don’t want to share my space.”
> Lone ranger: “I work best alone.”
> Old dog: “I already know how to do my work.”
> Zero-sum game: “Why should I share credit?”
> Inferiority complex: “They won’t want to work with
me.”
> Superiority complex: “Co-workers just slow me down.”
> Rejection of insufficient miracle: “I’ll wait for
a panacea.”
--
Before you can overcome personal resistance to agile, you must
understand it.
Personal bubble/social dysfunction. Agile demands
interpersonal interaction. Self-esteem issues, social dysfunctions,
jealousy, and grudges can make it hard for members to collaborate.
Lone ranger. Developers who seek to be the team’s guru or
hero, by staying late or mastering arcane code and skills, may fear
losing their esteemed status.
Old dog. It’s hard to abandon productive old habits
without certainty that new skills will prove to be even more
productive.
Zero-sum game. A classic dysfunction is viewing a
teammate’s failure as a personal success, and vice versa.
Inferiority complex. Some developers fear that
collaboration will expose their self-perceived weaknesses and devalue
them to the company.
Superiority complex. Some developers will object to agile
because working with their “inferior” teammates will “drag them
down.”
Rejection of insufficient miracle. Though agile software
development may help solve many problems, it may leave others
unsolved.
Civilization World Wonder quote: "The Taj Mahal rises above
the banks of the river like a solitary tear suspended on the cheek of
time."
–Rabindranath Tagore
Monday, September 30, 2013
Agile in a Flash 11
Got
Organizational Obstinance – The Idea
Agile in a Flash by Jeff Langr and Tim Ottinger (card #11)
> It can’t work here. “Our company is uniquely complex.”
> They won’t let us. “Our culture doesn’t support it.”
> Guilt by association. “Agile is like something else that failed.”
> Means/ends juxtaposition. “It doesn’t support our management style.”
> Inferiority complex. “We’re too afraid to improve the code.”
> Superiority complex. “We’ve been shipping on time just fine.”
> Rejection of insufficient miracle. “But it won’t solve all our problems.”
--
How will your team respond to the typical excuses when they want to try agile?
It can’t work here. Agile isn’t a rigid set of practices. You need only a team willing to start with the core values and incrementally grow together.
They won’t let us. Start small by tackling a few agile practices, and win over management with success and the real data behind it.
Guilt by association. A nonagile, semi-agile, or other nonwaterfall method may have failed for you in the past. That’s no reason to avoid a proper agile project.
Means/ends juxtaposition. Software management structures, ceremonies, and documents support developing software, not the other way around. Help your organization adopt new structures to support agile development.
Inferiority complex. Agile improves developers via teamwork and doesn’t leave people behind in their cubes while hoping the superstars deliver.
Superiority complex. If you’re perfect, why are you even considering agile? :-) If not, welcome to a world where we know we can always do better.
Rejection of insufficient miracle. “Nothing will ever be attempted if all possible objections must first be overcome.” —Samuel Johnson.
Civilization World Wonder quote: "O, let not the pains of death which come upon thee enter into my body. I am the god Tem, and I am the foremost part of the sky, and the power which protecteth me is that which is with all the gods forever."
–The Book of the Dead, translated by Sir Ernest Alfred Wallis Budge
Agile in a Flash by Jeff Langr and Tim Ottinger (card #11)
> It can’t work here. “Our company is uniquely complex.”
> They won’t let us. “Our culture doesn’t support it.”
> Guilt by association. “Agile is like something else that failed.”
> Means/ends juxtaposition. “It doesn’t support our management style.”
> Inferiority complex. “We’re too afraid to improve the code.”
> Superiority complex. “We’ve been shipping on time just fine.”
> Rejection of insufficient miracle. “But it won’t solve all our problems.”
--
How will your team respond to the typical excuses when they want to try agile?
It can’t work here. Agile isn’t a rigid set of practices. You need only a team willing to start with the core values and incrementally grow together.
They won’t let us. Start small by tackling a few agile practices, and win over management with success and the real data behind it.
Guilt by association. A nonagile, semi-agile, or other nonwaterfall method may have failed for you in the past. That’s no reason to avoid a proper agile project.
Means/ends juxtaposition. Software management structures, ceremonies, and documents support developing software, not the other way around. Help your organization adopt new structures to support agile development.
Inferiority complex. Agile improves developers via teamwork and doesn’t leave people behind in their cubes while hoping the superstars deliver.
Superiority complex. If you’re perfect, why are you even considering agile? :-) If not, welcome to a world where we know we can always do better.
Rejection of insufficient miracle. “Nothing will ever be attempted if all possible objections must first be overcome.” —Samuel Johnson.
Civilization World Wonder quote: "O, let not the pains of death which come upon thee enter into my body. I am the god Tem, and I am the foremost part of the sky, and the power which protecteth me is that which is with all the gods forever."
–The Book of the Dead, translated by Sir Ernest Alfred Wallis Budge
Agile in a Flash 10
The
Right Process – The Idea
Agile in a Flash by Jeff Langr and Tim Ottinger (card #10)
> Continuous process flow
> Pull work to avoid overproduction
> Work like the tortoise, not the hare
> Stop to fix problems
> Standardize tasks
> Expose problems with visual control
> Use only reliable technology that serves people and process
--
The Toyota Production System says “the right process will produce the right
results.”
Continuous process flow. A process stream that requires continual delivery creates
transparency; any blips in the process are sorely felt downstream.
Pull work to avoid overproduction. An overproducing group produces waste by
creating backlog. Produce only when the downstream group requests it.
Work like the tortoise, not the hare. Rushing repeatedly to short-term deadlines
can produce poor quality and burnout that destroys products and teams.
Stop to fix problems. Small problems quickly pile up into progress-killing waste.
Engage the whole team, and correct the problems before moving on.
Standardize tasks. You cannot hope to continually improve without some foundational
level of standardization.
Expose problems with visual control. You cannot fix a problem easily until
everyone admits it’s a problem. Don’t bury your mistakes.
Use only reliable technology that serves people and processes. Your team has
to be masters of the tools they use.
Civilization World Wonder quote: "The art of war teaches us to rely not on the likelihood of the enemy's not attacking, but rather on the fact that we have made our position unassailable."
–Sun Tzu
Agile in a Flash by Jeff Langr and Tim Ottinger (card #10)
> Continuous process flow
> Pull work to avoid overproduction
> Work like the tortoise, not the hare
> Stop to fix problems
> Standardize tasks
> Expose problems with visual control
> Use only reliable technology that serves people and process
--
The Toyota Production System says “the right process will produce the right
results.”
Continuous process flow. A process stream that requires continual delivery creates
transparency; any blips in the process are sorely felt downstream.
Pull work to avoid overproduction. An overproducing group produces waste by
creating backlog. Produce only when the downstream group requests it.
Work like the tortoise, not the hare. Rushing repeatedly to short-term deadlines
can produce poor quality and burnout that destroys products and teams.
Stop to fix problems. Small problems quickly pile up into progress-killing waste.
Engage the whole team, and correct the problems before moving on.
Standardize tasks. You cannot hope to continually improve without some foundational
level of standardization.
Expose problems with visual control. You cannot fix a problem easily until
everyone admits it’s a problem. Don’t bury your mistakes.
Use only reliable technology that serves people and processes. Your team has
to be masters of the tools they use.
Civilization World Wonder quote: "The art of war teaches us to rely not on the likelihood of the enemy's not attacking, but rather on the fact that we have made our position unassailable."
–Sun Tzu
Agile in a Flash 9
Toyota
Production System (TPS) Principles – The Idea
Agile in a Flash by Jeff Langr and Tim Ottinger (card #9)
> Continuous improvement
> Respect for people
> Long-term philosophy
> Develop the right process
> Develop your people and partners
> Continuously solve root problems
--
Your agile team—scratch that, any team—can learn plenty from Toyota Production System principles.
Continuous improvement. Not only must we continuously reflect and adapt, but we must base such decisions on facts that derive from the true source.
Respect for people. Even if a process fosters the delivery of quality software, it is a failure if it does so at the expense of the workers who employ it.
Long-term philosophy. Building a process around short-term goals leads to a sloppy product. Teams must take a larger product focus.
Develop the right process. The software development process is not about controlling a project with voluminous documentation and mandates. Allow each team to devise and continuously tweak their own mechanisms for success.
Develop your people and partners. The best agile teams seek not only to continually learn more and challenge themselves but to promote this attitude in
others with whom they interact.
Continuously solve root problems. All involved should go to the problem to see it firsthand and work with the whole team to reach a consensus on how to
solve it.
Civilization World Wonder quote: "The ancient Oracle said that I was the wisest of all the Greeks. It is because I alone, of all the Greeks, know that I know nothing"
–Socrates
Agile in a Flash by Jeff Langr and Tim Ottinger (card #9)
> Continuous improvement
> Respect for people
> Long-term philosophy
> Develop the right process
> Develop your people and partners
> Continuously solve root problems
--
Your agile team—scratch that, any team—can learn plenty from Toyota Production System principles.
Continuous improvement. Not only must we continuously reflect and adapt, but we must base such decisions on facts that derive from the true source.
Respect for people. Even if a process fosters the delivery of quality software, it is a failure if it does so at the expense of the workers who employ it.
Long-term philosophy. Building a process around short-term goals leads to a sloppy product. Teams must take a larger product focus.
Develop the right process. The software development process is not about controlling a project with voluminous documentation and mandates. Allow each team to devise and continuously tweak their own mechanisms for success.
Develop your people and partners. The best agile teams seek not only to continually learn more and challenge themselves but to promote this attitude in
others with whom they interact.
Continuously solve root problems. All involved should go to the problem to see it firsthand and work with the whole team to reach a consensus on how to
solve it.
Civilization World Wonder quote: "The ancient Oracle said that I was the wisest of all the Greeks. It is because I alone, of all the Greeks, know that I know nothing"
–Socrates
Agile in a Flash 8
Pillars
of Software Craftsmanship – The Idea
Agile in a Flash by Jeff Langr and Tim Ottinger (card #8)
> Care
> Learn
> Practice
> Share
--
Via the Craftsmanship Google Group (http://groups.google.com/group/software_craftsmanship), Jason Gorman offered this nicely concise statement of Craftsman ethics, abbreviated and quoted here:
Care. We care about the quality of the work we do. It should be as good as we’re capable of making it.
Learn We learn from our mistakes and from examples, books, blogs, webinars, magic beans, and electric parsnips. When we’re exposed to good examples, we learn better, so it’s important to have good influences.
Practice. We learn by doing, so we practice. Continuously. We internalize our knowledge and build our “software development muscles” and the necessary reflexes and muscle memory needed to be a productive programmer. You can no more master a skill like refactoring by reading a book on it than you can master riding a bicycle by reading the manual. It takes practice—good, focused, measured practice.
Share.We share what we’ve learned. We build the good examples others learn from. We are all simultaneously masters and apprentices, teachers and students, mentors and mentored, coaches and coachees..
Civilization world wonder quote:
"I think that if ever a mortal heard the word of God it would be in a garden at the cool of the day."
–F. Frankfort Moore
Agile in a Flash by Jeff Langr and Tim Ottinger (card #8)
> Care
> Learn
> Practice
> Share
--
Via the Craftsmanship Google Group (http://groups.google.com/group/software_craftsmanship), Jason Gorman offered this nicely concise statement of Craftsman ethics, abbreviated and quoted here:
Care. We care about the quality of the work we do. It should be as good as we’re capable of making it.
Learn We learn from our mistakes and from examples, books, blogs, webinars, magic beans, and electric parsnips. When we’re exposed to good examples, we learn better, so it’s important to have good influences.
Practice. We learn by doing, so we practice. Continuously. We internalize our knowledge and build our “software development muscles” and the necessary reflexes and muscle memory needed to be a productive programmer. You can no more master a skill like refactoring by reading a book on it than you can master riding a bicycle by reading the manual. It takes practice—good, focused, measured practice.
Share.We share what we’ve learned. We build the good examples others learn from. We are all simultaneously masters and apprentices, teachers and students, mentors and mentored, coaches and coachees..
Civilization world wonder quote:
"I think that if ever a mortal heard the word of God it would be in a garden at the cool of the day."
–F. Frankfort Moore
Friday, September 20, 2013
Agile in a Flash Card No. 7
Redefining
Discipline – The Idea
Agile in a Flash by Jeff Langr and Tim Ottinger (card #7)
Redefining Discipline
> Work attentively
> Work on one thing at a time
> Shorten feedback loops
> Continuously reflect and adapt
> Know when to call it a day
> Push back when it matters
--
In a pre-agile world, discipline was defined mostly as the inclination to stick with a plan. An agile workflow is very disciplined but with a different definition of discipline.
Work attentively. Try to keep up but also keep track. Note which aspects of your work system are hard, clunky, troublesome, or slow.
Work on one thing at a time. Do not dilute your effort and your attention by taking on multiple tasks at once. Take one tiny, verifiable step at a time.
Shorten feedback loops. How long until you detect defects or reap benefits? Aggressively simplify your process to shorten that time.
Continuously reflect and adapt. Invest in the team’s ability to easily produce a quality product. Always build a better “next week.”
Know when to call it a day. A few more minutes of digging might crack a tough problem, but so could a night’s sleep. Learn when to stop.
Push back when it matters. Nobody wants a contentious employee. So, choose your battles carefully, but always protect the product, team, and company by advising against changes that oppose the values stated in the manifesto.
Agile in a Flash by Jeff Langr and Tim Ottinger (card #7)
Redefining Discipline
> Work attentively
> Work on one thing at a time
> Shorten feedback loops
> Continuously reflect and adapt
> Know when to call it a day
> Push back when it matters
--
In a pre-agile world, discipline was defined mostly as the inclination to stick with a plan. An agile workflow is very disciplined but with a different definition of discipline.
Work attentively. Try to keep up but also keep track. Note which aspects of your work system are hard, clunky, troublesome, or slow.
Work on one thing at a time. Do not dilute your effort and your attention by taking on multiple tasks at once. Take one tiny, verifiable step at a time.
Shorten feedback loops. How long until you detect defects or reap benefits? Aggressively simplify your process to shorten that time.
Continuously reflect and adapt. Invest in the team’s ability to easily produce a quality product. Always build a better “next week.”
Know when to call it a day. A few more minutes of digging might crack a tough problem, but so could a night’s sleep. Learn when to stop.
Push back when it matters. Nobody wants a contentious employee. So, choose your battles carefully, but always protect the product, team, and company by advising against changes that oppose the values stated in the manifesto.
- "Libraries are as the shrine where all the relics of the ancient saints, full of true virtue, and all that without delusion or imposture are preserved and reposed."
- –Sir Francis Bacon
Wednesday, September 18, 2013
Agile in a Flash Card No 6
Courage – The Idea
Agile in a Flash by Jeff Langr and Tim Ottinger (card #6)
> To always deliver quality work
> To simplify code at every turn
> To attack code the team fears most
> To make architectural corrections
> To throw away unneeded code and tests
> To be transparent, whether favorable or not
> To take credit only for complete work
Cowardly Lion: As long as I know myself to be a coward, I shall be
unhappy.
--
To always deliver quality work. Even when pressure mounts, never discard the practices needed to deliver quality code. See Card 13, Don’t Get Too Deep in Technical Debt.
To simplify code at every turn. Simple code reads faster and more clearly, which leads to fewer defects and more fluid development. Simplifying is investing in speed of development.
To attack code the team fears most. Fear of breaking ugly code makes a team dread changes instead of embracing them. Empower your team by getting that code under control.
To make architectural corrections. Systems may outgrow early architectural decisions. It takes courage to undertake changes that will affect existing code, even if the change is clearly for the better.
To throw away tests and code. Often the best results are produced by discarding a poor solution and reworking it. It takes far less time than you think.
To be transparent, whether favorable or not. If you “color” your reports about status, progress, or quality, you contribute to ill-informed decision making.
To take credit only for complete work. Incomplete work provides no business value! Don’t rationalize calling it “done” for status tracking purposes.
Agile in a Flash by Jeff Langr and Tim Ottinger (card #6)
> To always deliver quality work
> To simplify code at every turn
> To attack code the team fears most
> To make architectural corrections
> To throw away unneeded code and tests
> To be transparent, whether favorable or not
> To take credit only for complete work
Cowardly Lion: As long as I know myself to be a coward, I shall be
unhappy.
--
To always deliver quality work. Even when pressure mounts, never discard the practices needed to deliver quality code. See Card 13, Don’t Get Too Deep in Technical Debt.
To simplify code at every turn. Simple code reads faster and more clearly, which leads to fewer defects and more fluid development. Simplifying is investing in speed of development.
To attack code the team fears most. Fear of breaking ugly code makes a team dread changes instead of embracing them. Empower your team by getting that code under control.
To make architectural corrections. Systems may outgrow early architectural decisions. It takes courage to undertake changes that will affect existing code, even if the change is clearly for the better.
To throw away tests and code. Often the best results are produced by discarding a poor solution and reworking it. It takes far less time than you think.
To be transparent, whether favorable or not. If you “color” your reports about status, progress, or quality, you contribute to ill-informed decision making.
To take credit only for complete work. Incomplete work provides no business value! Don’t rationalize calling it “done” for status tracking purposes.
- "Why man, he doth bestride the narrow world like a colossus, and we petty men walk under his huge legs, and peep about to find ourselves dishonorable graves."
- –William Shakespeare, Julius Caesar
Agile in a Flash Card No1
Why
Agile? - The Idea
from Agile
in a Flash (by Jim Langr and Tim Ottinger)
"Get
us on the same page
Imagine
the enmity disappearing as business and development team up to
deliver ongoing value to customers!
Get
product out the door
Quarterly
releases? That's for sisses! With iterative development, you can
deliver every few weeks or even every few days.
Drive
down risk
Short
release cycles allow you to get real, end-user feedback long before
you have invested too much in a risky feature.
Learn,
adapt, deliver!
Feedback
from real users keeps you in tune with the changing marketplace.
Internally, you can continually improve your team with retrospection
(if you are willing to truly examine your processes).
Take
pride in your craft
Using
agile technical practices such as test-driven-development,
refactoring, and automated tests, you can be proud of the low-defect
product you send out the door.
True
transparency
You
cannot miss the charts on the walls and the ongoing conversations in
an agile team room. It is obvious that team members have and share
more information than in non-agile projects (when communication is
open).
The
joy of building
In
agile, everyone can experience the excitement of working in a true
team that delivers cool, working stuff all of the time. "
The nice thing about agile is the adaptability of the process to changes in the environment. This process however requires that teams are communicating with each other and the other stakeholders of the projects. They also must be willing to truly examine processes whether good or ill to reevaluate SWOT as they progress through projects. By continually examining via retrospection, teams can build on successes and avoid letting obstacles become complete derailing project stoppers. Even people who think they run agile shops have to put aside egos, reduce finger-pointing, and really examine how they are conducting processes because success is not about egos. Successful projects are about meeting deadlines, budgets and estimations. Successful projects are about getting the most productivity from your team to achieve the group's objectives in the projects.
Agile in a Flash No 2
The
Agile Values, aka the Agile Manifesto - The
Idea
Agile
in a Flash by Jeff Langr and Tim Ottinger (card #2)
Individuals
and interactions
over
processes and tools
Working
software
over
Comprehensive documentation
Customer
collaboration
over
Contract negotiation
Responding
to Change
over
Following a plan
That
is, while there is value in the items on the right, we value the
items on the left more.
Agile
software development teams collaborate and adapt with minimal
ceremony and overhead to deliver quality software.
You
may need “the things on the right” to success with agile, but it
is effective to bypass paperwork and just
talk to people.
Translating needs into written form is wasteful compared to having
your customer simply tell you what they wan and remain available to
answer questions.
Similarly,
working
software matters.
Documents? Not as much. Capture specifications in the product and its
tests through agile practices such as TDD and acceptance testing.
You
can diminish the importance of contracts if you negotiate
on a continual basis.
This involves an increase in transparency and trust, supported
greatly by the openness and heavy collaboration that agile promotes.
Plans
are valuable, but your customer and the marketplace care less about
your plans than about you delivering
software that fits their ever-changing needs."
Agile in a Flash - Card No 5
Agile
in a Flash by
Jeff Langr and Tim Ottinger (card
#5)
>
Freedom to change
>
Energized
team
>
Communication
with customer
>
Collaboration
>
Attention
to quality
>
Incrementalism
>
Automation
--
Taking
the Agile Manifesto’s values and principles one step further, these
are the make-or-break factors for a team wanting to be agile:
Freedom
to change
A team must be allowed to own and change its process. Tampering
diverts from shipping quality software.
Energized
team
A winning agile team is eager to deliver value, collaborates freely,
and never bypasses quality controls even under pressure.
Communication
with customer
The best agile teams are in constant dialogue with an enthusiastic,
individual, dedicated customer who understands and communicates the
product vision.
Collaboration
Get past cube mentality! Meetings aren’t collaboration; working
together in your code base is.
Attention
to quality
Lack of attention slows you down until you can no longer meet
customer demand. Make quality part of everything you do.
Incrementalism
Yet- small er steps to everything (including retrospection) allow you
to verify whether each step got you closer to the end goal.
Automation
Agile cannot work unless you automate as many menial, tedious, and
error-prone tasks as possible. There’s just not enough time!
Iowa
beat ISU 27-21...
Agile in a Flash #4
Role-Playing
in Agile
–
The Idea
Agile
in a Flash by
Jeff Langr and Tim Ottinger (card
#4)
>
Customer:
Helps define the product
>
Programmer:
Helps construct the product
>
Tester:
Helps verify the product works as defined
>
Tracker:
Helps gather and present useful metrics
>
Coach:
Helps guide the team to success
>
Coordinator
(optional): Helps manage external communication
--
In
an agile team, everyone helps out, doing whatever it takes to deliver
a useful, high-quality product. You are not bound by your job title.
A tester might track team metrics, a programmer might help define
acceptance criteria, and so on.
The
customer
has special responsibility and authority, because they are
responsible for the product’s functionality and user-facing design.
Their supporting cast may include business analysts, product owners,
and others who help define the product (including testers), but
everyone on the team is responsible for advising the customer.
Programmers
(and other technical folks, such as architects and support
technicians) are responsible for the internal design, construction,
and maintenance of the product.
A
coach
helps educate and guide your team, shunning command-and-control
approaches. They help your team devise their own rules and protocols.
The best coaches help teams mature to the point where the team no
longer needs them.
We
substitute team
coordinator
for roles like manager, project manager, and Scrum Master. The
coordinator buffers the team from outside interference and
distraction. They might communicate schedules, handle incoming
requests, and smooth interpersonal problems.
LibreOffice
kind of sucks...
Agile in a Flash Card #3
Principles
Behind the Agile Manifesto
– The Idea
Agile
in a Flash by
Jeff Langr and Tim Ottinger (card
#3)
>Satisfy
the customer through early, continuous delivery
>Welcome
changing requirements, even late
>Deliver
working software frequently
>Businesspeople
and developers collaborate daily
>Build
projects around motivated individuals
>Convey
info via face-to-face conversation
>Primary
progress measure: working software
>Maintain
a constant pace indefinitely
>Continuously
demonstrate technical excellence
>Simplify:
maximize amount of work not done
>Self-organize
.>Retrospect
and tune behavior
--
The
Agile Manifesto values can sound “warm and fuzzy,” but you will
find that its dozen principles (...the originals at
http://agilemanifesto.org)
provide a much meatier description of agile.
Agile
is foremost about continually
and incrementally delivering quality software to
a customer who must constantly
juggle changing requirements
in order to compete in the marketplace. Your job: make
your customer happy.
You’ll
best succeed if your team is highly
motivated.
They must communicate
and collaborate at least daily,
which is easiest if everyone
is in the same room, talking face-to-face.
The
team must embrace technical
excellence,
an essential part of maintaining
a constant delivery pace indefinitely.
By self-organizing, the team derives the best possible architectures,
requirements, and designs.
To
maintain a consistent rhythm of delivery, the team must adapt
through retrospection.
An incremental mindset helps sustain this rhythm: keep
it simple
by introducing features and complexity only when demanded, no sooner.
Always
remember it’s about delivering the good software, baby. Measure
progress and success by your ability to continue to deliver.
Here's
to hoping for a great Hawkeye Victory!
Subscribe to:
Posts (Atom)