Archive for the ‘Process Improvement’ Category

h1

Video Blog : Distractions Kill Teams

January 2, 2015

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

Also visit:

Websites:   www.ProjectPragmatics.com  and

http://www.JohncMaxwellGroup.com/bobmaksimchuk

h1

Are You Human?

October 8, 2014

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 .

h1

ScrumMaster as Shepherd

April 22, 2012

The concept of servant leadership seems to be difficult for some new ScrumMasters (and others) to fully comprehend.  It is so contrary to many corporate cultures.  So let’s take a look at another role that combines both serving and leadership behaviors: the Shepherd.

 

Some herd animals, such as sheep, have a better chance to thrive if they have a shepherd.  In order to help them thrive, a shepherd must understand the flock, just as a ScrumMaster must understand the team he/she is working with.  For example, there are many types of sheep just as there are different people with different skills and different behaviors on an agile team.  They are NOT interchangeable “resources”.

 

Flocks of sheep have certain dynamic behaviors.  Sheep tend to congregate and behave as a group once their group reaches a certain number.  A successful team needs to reach “critical mass” regarding the competencies needed to be a successful agile team.  A ScrumMaster must understand this and promote the proper composition of a team, by working to have the right sheep in the flock (e.g. motivated, highly skilled).  The ScrumMaster must also be understanding as the team goes through the well-known form/storm/perform cycle.

 

Sheep are prey animals.  In toxic corporate cultures, development teams may become prey for overzealous Project Managers or other corporate creatures.  Just as team members are not really “sheep” or “pigs” (even though we use those terms affectionately), a ScrumMaster is not a “sheep dog”.  Sheep dog is a weak analogy.  A ScrumMaster can’t just “bark” back at people in the typical corporate hierarchy – at least not for long, without being sent “out to pasture”.  The ScrumMaster needs to be a shepherd and intelligently navigate the political minefields while not letting the flock fall prey to predators of time or energy.

 

Sheep congregate often (a daily standup?) and do it well.  Sheep are gregarious when congregated.  However, the Shepherd must still work to draw out the quiet people during stand-ups or planning poker sessions.  When you lose a sheep or a team member disengages from the team or otherwise gets lost on the agile journey, the ScrumMaster must seek them out and bring them back to the flock.

 

Even these simple and cursory understandings can help the new ScrumMaster serve and lead their teams.  Serve them well shepherds and you will be on your way to servant leadership, leading your flock to those greener agile pastures.  

(See more at www.ProjectPragmatics.com .)

h1

Agile Heresy

January 2, 2012

 Those who do the work are the best people to estimate what it takes to perform the work.  Makes sense.  Sounds reasonable.  The problem with such a definitive statement is the subjective word “best”.  Most of us read “best qualified” into that statement.  But what if the “best” person to do the estimation, won’t?  Have you ever worked with people on an agile team who don’t want to contribute to the backlog item estimation activity?  Sometimes a rigid corporate culture causes people who are, or perceive themselves to be “lower on the food chain” to say little and thereby avoid perceived conflict or anger of a more senior person.  Sometimes it’s a cultural behavior.  Sometimes fear.  Sometimes shyness.

 One successful team that I coached found a workable solution.  They selected a small sub-team from the more senior people on the team.  This sub-team did the estimation for the whole team.  It worked well and they have been very successful.

 But do you think this is agile heresy?  If so, how would you otherwise fix such a situation?

 Paraphrasing that old adage: You can lead a horse to water, but you can’t make him estimate.

h1

Wasting Time…Agile-ly

April 1, 2011

You have probably heard of Bruce Tuckman’s model describing the stages of group development – Form, Storm, Norm, and Perform.   Unfortunately many in the agile community seem to be stuck in the storm stage.  You see it in discussions that often center on positions such as: “You’re not really agile unless you are doing <insert favorite agile practice here>” or “<Insert practice being disparaged here> is not agile.  <Insert agile theory here> is agile.” or “<Insert agile solution being sold here> is the ‘right’ or ‘only’ way to do agile.” 

The latest skirmish line I have noticed is the Bottom Up vs. Top Down agile adoption arguments.  In general, the bottom up camp supports adoption starting at the team level, with adoption bubbling up, eschewing the heavy hand of corporate process improvement initiatives.  The top down camp posits that bottom up won’t produce sustainable change and that adoption must be driven from the organization level, pushing down.  (Hmmm. I wonder what Friedman and Keynes would think.) 

Why waste time entertaining such squabbles?  Stepping back to get a little perspective, clearly for any significant change to be successful you have to approach it from both the top and bottom.  The people must be educated and mentored on the new competencies.  The organization must create a structure and environment in which the people and the new changes can thrive. 

Both Dan Akerson and Matt Barcomb pragmatically discuss how to introduce agile from the bottom without ignoring the need to change the organization at the top. 

What successful approaches have you experienced (from top or bottom) that might help others improve their agility?

h1

Has Your Agile Ship Sailed?

December 8, 2010

Sorry agile purists.  In the real world, most development groups that are using agile techniques (a surprisingly small percentage vs. the industry hype) are not using a “pure” agile approach.  They are using a blend of agile and waterfall techniques to the tune of more than 10 to 1, according to a recent article on Application Development Trends.  The article discusses a European survey of this topic published by a tool vendor.  (Caveat Emptor – Remember if you choose to download and read the actual “study”, it is really a vendor marketing piece based on the survey results – not the actual survey).  I guess the assertion that “waterfall is dead” is as premature as that of the mainframe also being dead.

 Is anyone surprised?  Contrary to what we are constantly barraged with by the agile marketers shouting “Agile, agile!” there is no need to swallow the agile elephant whole.  If you are in an organization that is not using agile techniques, don’t be tempted to lunge headlong into adopting everything agile, just because think you are missing the boat.  Not so.  This article / survey show what other studies have recently shown – that organizations doing agile are not (yet) in the majority.  Another indicator is that the primary tools being used to manage agile projects are still Microsoft Excel and Project.  And many groups are just using ad-hoc tools or working manually.

 So you still have time.  Learn from the majority of the organizations surveyed and adopt agile practices a few at a time.  Target the areas where you have the most problems and try out some lightweight practices.  Find out what works for you, give it time to diffuse into your organization, and then move on to adding additional practices. 

 What you will find is that it is not usually about the tools or about the agile practices themselves.  Most of the challenges in agile adoption are about people and organizations.  This survey cites resource management, cultural issues, change management, perceived loss of control, and executive buy-in as major stumbling blocks.  A “tools first” approach will not solve these.  Nor will a process-only approach.  While you are adopting more lightweight techniques, also look at your people issues and assess whether those can be resolved.  Otherwise they will be the rocks upon which your agile ship will run aground.

h1

Simplify the UML?

November 18, 2010

I am continually amazed at the serendipity of events that occurs everyday. A short time ago I was having lunch with an industry insider when he mentioned the beginnings of a movement to simplify the UML. Having read the 700+ page UML specification a number of times (Sadistic, isn’t it?) it immediately struck me as a good idea. While software modeling is an “acknowledged” technique, it still is not a “standard” practice on most software projects. From the common, repeating questions that I have been asked over the years, many people still struggle with how to do it well. Modeling has a way to go to become truly mainstream. So a simpler UML sounded like a fine idea. But…Read More.