Agile Pneumonia and the Manifesto Blues

Sung to the tune of Rockin’ Pneumonia and the Boogie Woogie Blues by Johnny Rivers, J.Vincent and H. Smith.

(If you don’t know it, you can listen here first >>> https://www.youtube.com/watch?v=UvJ78hYI6wk )

 

Agile Pneumonia and the Manifesto Blues

Blocked tasks, they decorate out wall
I wanna holler, but the team room’s small

Old PM just doesn’t know what to do
I got the agile pneumonia and the manifesto blues

Large stories, medium, and small
Do anything so that our points don’t fall

New Scrummaster’s got a hold of me too
I got the agile pneumonia and the manifesto blues

Squeeze in more stories with two days to go
We’d deliver but our velocity’s low

Business just doesn’t understand what we do
I got the agile pneumonia and the manifesto blues

Only an hour with the new PO
That’s not how agile’s supposed to go

Wish the PO would guide what we do
I got the agile pneumonia and the manifesto blues

Long day and now I’m hurryin’ home
Can’t finish planning ‘cause we’re takin’ too long

Let’s do this right or I think that I’m through
I got the agile pneumonia and the manifesto blues.

====================
WANT TO USE THIS ARTICLE IN YOUR E-ZINE, BLOG OR WEB SITE?
You can, as long as you include the following complete text with it: “Bob Maksimchuk is a Principal Consultant at Project Pragmatics, LLC., specializing in helping software development teams GET WORK DONE by introducing: PRACTICAL techniques, STREAMLINED process, and FOCUSED training and mentoring, all specific to your team’s needs. Visit now at http://www.ProjectPragmatics.com. All rights reserved © 2015 Project Pragmatics, LLC.”

Video Blog : Distractions Kill Teams

To see video click – www.screencast.com/t/b9lFNBIt

Also visit:

Websites:   www.ProjectPragmatics.com  and

http://www.JohncMaxwellGroup.com/bobmaksimchuk

Are You Human?

Isaac Asimov’s science fiction short story “The Bicentennial Man” tells the tale of a robot named Andrew. With the help of some human benefactors, over a long time, Andrew replaces his robotic systems with biological parts, piece by piece by piece. So the question becomes: When does Andrew stop being a robot and becomes a human (or something else)?

Does Andrew’s behavior remind you of your team? Or yourself perhaps? Maybe you are well on your agile journey. Maybe you are just starting to adopt agile. Even with the best intentions you may find yourself facing the same question as Andrew if you’re not careful.
What I have found in many teams and organizations is that there is almost an innate drive to change things as soon as they learn (but have not mastered) them – ‘Now that we’ve learned this agile stuff, let’s:

a) Not have the daily scrum every day
b) Not have the whole team participate in planning
c) Just have the “leads” do the estimation and tasking
d) Not work with the Product Owner regularly – just at the end of the iteration is fine
e) Ignore our velocity when planning the iteration – the Project Manager will tell us what to commit to
f) Some of the above
g) All of the above
h) More than all of the above.’

Sound familiar?

Now I’m not an agile purist. I believe in adopting agile pragmatically. Once you have mastered the basics and are successfully delivering value regularly and you want to adopt your approach to improve how it can work better in your organization, try it. It may work.

But don’t do this haphazardly. Make sure you understand why the various agile techniques are what they are and do what they do. Consider carefully why you want to change things – to make it “easier” or “save time” or to just be more personally comfortable? Make any justifiable changes like you deliver software – incrementally. Then inspect and adapt the change as appropriate. Just be patient. Get good at this stuff first. There is no rush.

If you keep changing things too quickly and prematurely you may find yourself in a dilemma similar to Andrew. But you won’t be asking “Am I still a robot?” You will find yourself asking “Am I still behaving agilely?

For more like this, videos, and other things please visit www.ProjectPragmatics.com .

The Baker’s Dozen of Coaching Leadership

1. Be Dedicated – to your client, your team, yourself. Commitment builds trust.
2. Be Curious – about your profession, your client, other fields. Learn continuously. If you think you know it all, you have limited your potential.
3. Be Humble – no matter how successful, smart, or well-known. Arrogance destroys relationships.
4. Be Energetic – Do you bring energy into the room or do you drain the life out of it?
5. Be Engaged – Your client doesn’t value an aloof advisor who provides little value.
6. Be Perceptive – See their gifts. Does your team have cheerleaders (encouragers), pragmatists (guides), jokers (morale builders), dreamers (visionaries)? Leverage these soft abilities as much as hard skills.
7. Be Empathic – See their needs. Be sure to serve their actual needs, not yours.
8. Be Resourceful – When your team has no answer and neither do you, take the initiative to go find a new option or approach for them that may be useful.
9. Be Uplifting – Don’t criticize the doubtful, the non-believers. Encourage and uplift them.
10. Be Persistent – when you hear “we’ve always done it this way”. You are a change agent. You can’t sail the seas when you are tied to the dock.
11. Be Resolute – Reject rejection. Take the high road. Repay your critics with kindness, service, and understanding.
12. Be Fun – Celebrate with your teams whenever they succeed, big or small.
13. Be Caring – Remember, they are not assets or resources. They are real people. With real lives. Just like you.

Come visit http://www.projectpragmatics.com .

 

Tis the Season

As we fly through this Christmas season, give your teams the gift that will mean the most to them – empowerment.  The cost to you – nothing.  What do you get in return?  Speed, productivity, increased commitment and an overall happier team.

But you say your team is not able to self-organize?  Teach them.  Guide them.  If they are willing, lead them by showing why their particular strengths and skills are needed.  Show them why their contribution is important.  Show you are confident that they can self-organize and be successful.

You say it’s easier just to tell them what to do?  Do you really want them to bring every little problem to you for resolution?  (If so, I suggest you and your ego spend some quiet time in self-examination as to why you like that.)

Why would you want to take away from your team the opportunity of becoming the professionals that they truly are?  (Note to HR:  They are professional people, not “resources”.)  Give your team the opportunity.  Give them the freedom to grow.  Give them an assist, not the whip.

And in this way, give yourself the gift of developing into a true servant leader.  After all, this is the season of giving.

The Agile Scorpion

A frog approaches a stream and sees a scorpion by the bank.  The scorpion cannot cross the stream alone, so he asks the frog to carry him across the stream on its back.  The frog is wary of the scorpion and says “You might sting me and I will die.”  The scorpion assures the frog he wouldn’t do that because then they both would die.  The frog agrees.  Then halfway across the stream the scorpion stings the frog.  The frog begins to sink.  Before they both drown the frog asks “Why?”  The scorpion replies: “It’s my nature.”

This Aesop’s fable proclaims a warning for all of those who are on their agile journey.  Agile transformation is difficult enough.  You must also watch out for scorpions.  While change is hard for many people, the scorpions you may find, as in the story, have no intention of changing – but they won’t tell you that.  They could take the form of a team member, a manager, someone from another department that “supports” your team, an external business partner, and so forth.

It is truly unfortunate that the agile change “paralyzes” some people, but it does.  The level of change is significant.  So if you detect a scorpion among those on the agile journey with you, you can’t afford to tolerate their dangerous nature.  You will put your project and your agile transformation at significant risk.  Let them go be productive somewhere else.  You can’t afford to take the chance.

For more visit http://www.ProjectPragmatics.com

Sitting In A Teamroom Makes You As Agile As Sitting In A Garage Makes You A Chevy

You have a task board in your teamroom that you use to track the status of your users stories and tasks. But do you have any idea what is a reasonable number of tasks to have in work at any one time? The burndown chart that your tooling or your scrummaster makes is posted – isn’t it? Do you use it to understand the likelihood that your work for this sprint will be completed as planned? In every planning session you dutifully use Planning Poker for estimation. However, do you understand why using it is important and why this type of estimation actually works?

A professional mechanic understands more than just how to use the tools that are in the garage. The professional mechanic also understands how the tools work and why. It’s great that your team has learned many of the various agile techniques. But if you haven’t learned why those techniques work, you risk using them improperly, putting your success in jeopardy.

There is an old story about a young woman who is preparing her first holiday feast for the whole family, which included making a delicious glazed ham. She remembered, as a young girl, watching her mother cook. She called her mother to ask her why, when she cooked ham, she cut off the end of the ham before cooking. Her mother answered “Because my mother did it that way.” Now more curious, they called the grandmother and asked why she cut of the end of the ham before cooking. Grandmother told them it was because her mother did it that way. They were very fortunate that their Great-Grandmother was still around, so they called her and asked why she cut of the end of the ham before cooking. Great-Grandmother’s answer was simple…her roasting pan was too small.

Do you know “the whys” behind the agile techniques you do?
________________________________________________________________________
www.ProjectPragmatics.com
Improving Your Software Processes and Practices
Agile Adoption and Transformation