Posts Tagged ‘project pragmatics’

h1

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

July 8, 2013

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

Advertisements
h1

Burndown Bingo – An Agile Anti-Pattern

November 6, 2011

Your newly minted global agile team is dutifully performing the rituals typical of agile development.  They do their morning scrum, they update their remaining task hours, review their burndown chart, and so forth every day.  The end of the sprint comes, they deliver successfully, and during the retrospective the business praises them highly for how their actual burndown tracks closely with the ideal trend line on the burndown chart.  The team is happy.

The next sprint is going along well but mid-sprint the business looks at the burndown and notices the actuals are not tracking so closely anymore (not wildly off course, just noticeably more than the last sprint).  At the next standup the business raises mild alarm at the deviation and wants to know why, why?  Now the team is not so happy.  One of the distributed teams appears very concerned about the displeasure expressed by the customer.

As the next sprint is planned, the product backlog item estimates from the distributed team seem unusually uniform and unrealistically high.  The hours estimated for their sprint tasks are “healthy” also.  Amazingly, during the sprint the actuals now track EXACTLY with the ideal trend line.  Not close – exact.

Hmmmm.  Could just be random luck and serendipity.  Could be an error in the burndown calculations.  Or could it be that the worried, distributed team (who are the last chronologically to update their hours) has enough “padding” in their estimates that after the other teams update their hours, the worried team updates their remaining hours so precisely that – BINGO! – the actuals precisely match the projection,  every day.  Naaah!  Couldn’t be. …………. Could it?

Ever seen such an anomaly on your projects?

h1

Psyching Out Agile Teams

July 13, 2011

I recently read a study[1] on the psychological needs of agile teams. Various factors thought to affect software practitioners’ acceptance of agile orientation were studied. One of the interesting characteristics was the team’s perceived support of their supervisors and coworkers. The study findings show that if team members perceive a high level of support from their supervisors and coworkers, this will lead to a high level of agile orientation in the team, especially for junior team members.

But what about the inverse? What about a senior manager or member of the team who is overtly negative about the agile changes? The study does not discuss this, but I don’t think we need a study to understand what happens when someone, especially someone in a supervisory roll, disparages a change. In the agile teams I have coached, when a negative influence is injected, the team members often “freeze up”. They’ll still do their jobs, but enthusiastically participating, engaging with other members, and doing whatever it takes, fades. You can’t blame them. After all, if they don’t perceive any support, or perceive opposition, why would they work all out for the change? If senior management is not committed why should the team be? This is anathema for a team trying to go agile.

So what to do? I witnessed the solution on a team that had one strong negative voice. But her manager was always very positive on agile. When this negative person’s manager entered the room, as the study’s results would predict, her overall negative behavior stopped and her uncooperative, challenging behaviors disappeared. She became cordial, cooperative, understanding. In a word, professional. In his absence, her behavior relapsed. Over time, with enough exposures and project successes, her negative behaviors began to moderate.

So if you are in this situation (i.e. a negative person is dragging your team down) and you can’t replace this person and you have access to a senior person who is positive, try to get them involved supporting the team, to mitigate the negative behaviors.

This study is another indicator of how important team composition is. Have you encountered individuals whose presence strongly impacted (for good or bad) the behaviors of their team mates?

For more free articles and resources please visit http://www.ProjectPragmatics.com.
________________________
1 – Agile Orientation and Psychological Needs, Self-Efficacy, and Perceived Support: A Two Job-Level Comparison; Seger, Hazzan, and Bar-Nahor

====================
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 © 2011 Project Pragmatics, LLC.”

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

Perfect Questions?

November 29, 2010

During a recent discussion I was having with a colleague who is an Agile Coach and Business Analyst, I asked her what the BA community was interested in regarding the practice of business analysis. Her answer surprised me. She said what many BAs want is the perfect list of questions to ask their clients. The perfect list of questions? Really? Who has that? For all situations?

Instead of the perfect list, how about a relevant list? How could that be created? What if you had a guide that could help you see what to ask? You do. Read More…

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.