Posts Tagged ‘maksimchuk’

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.

h1

The Leadership and Communication Lessons of Josey Wales – Part 3

August 27, 2010

The scene: Josey and his injured young rebel friend furtively approach a river crossing. There they meet three very interesting people – the boatman, Sim Carstairs, who ferries people across the river, Granny Hawkins, who provides supplies and “poultices” to travelers, and a fastidious carpetbagger, wearing a white suit, selling bottles of a cure-all elixir. It is these new characters, not Josey, that teach us a few interesting leadership and communication lessons. Read more…

h1

What Would You Like To See…For Free?

August 17, 2010

We are beginning a project to develop freely available online content. But first, we need your opinion on what topics this content should cover. Please take a moment to answer these five quick questions so that we can provide you the information that you need. Click here to go to the survey. Thanks for your input.

h1

The Leadership and Communication Lessons of Josey Wales – Part 2

August 2, 2010

[If you missed part 1 of this series you can read it here. Spoiler alert: This series will incrementally reveal the plot of this movie. If you have not seen the movie (Where have you been?), I recommend you get the movie and enjoy it prior to reading this series.]

The scene: After his family and farm are destroyed, Josey joins with a group of rebels who fight a guerilla war against the Union. The fight drags on. Eventually, the group’s leader (Fletcher) convinces everyone, except Josey, to turn themselves in to the Union soldiers. Fletcher had negotiated amnesty for the band of rebels. What the rebels did not know was that he did it for a price. The men surrendered and were killed by the Union soldiers. Despite a valiant effort, Josey could not save them. Only he and an injured young rebel (“the boy”) escaped.

All the rebels had been betrayed by the Union (including Fletcher – he believed they would receive amnesty). But Fletcher’s indignation was quickly quelled when he received a commission in the Union army and joins with Terrell (the leader of the “Redlegs” who had destroyed Josey’s family and farm, and was now a Captain in the Union) to hunt down Josey Wales.

Lesson 4: Politics Can Trump Skills. Sad to say, but technical and leadership skills are not a guaranteed shield against common organizational practices or malicious organization politics. Mergers, acquisitions, divestitures, outsourcing and the like often harbor many such organizational decisions that may put your career on the Wheel of Fate. Don’t bury your head in the sand (i.e. your projects). Stay tuned to organizational, market, and environmental changes. These can foreshadow subsequent changes that may have a direct impact on you.

Worse yet, malicious political maneuvers can leave innocent bystanders in the ditch. When I was working as a young developer, I witnessed my first political lesson. A pair of senior staffers who had been the heroes of an initial system delivery (and rightly so) were sidelined as the organization grew and grew, bringing in new teams and managers. The pair were no longer were in the limelight receiving honors and accolades.

During the next delivery cycle, what was later discovered that in order to engineer their personal return to hero status, the pair withheld critical technical information that resulted in a key software component not delivering on schedule. When the call went out for people to help this component team, the past heroes stepped in. The new team’s work was flushed. The old guard “discovered” the “problem”, fixed it, and voila! Heroes once again.

So be careful. Safety experts will tell you that situational awareness is critical to your personal safety. It’s critical to your professional safety also.

Lesson 5: Everyone Has A Price. Fletcher had a price…actually two. One to get his men to surrender. And a higher price to ignore the Union betrayal and track down Josey. What is your price? Oh, you don’t have one? Really? Before somebody asks you to do something that you know is wrong, unjust, unethical, or even illegal, do some self examination. Know your values. Know what principles you are committed to live by. Who are you at your core and what is your code of conduct? Think this through before the pressure comes – someday it will. Stay off the slippery slope Fletcher stepped onto.

__________________________________________________
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 and Founder 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. Copyright © 2010 Project Pragmatics, LLC. All rights reserved.”

h1

The Leadership and Communication Lessons of Josey Wales – Part 1

July 21, 2010

Sometimes you can learn important lessons from unconventional sources. If you are unaware, the classic 1976 movie western The Outlaw Josey Wales, set near the end of the U.S. Civil War, was directed by and starred Clint Eastwood, who played the main character Josey Wales.  The writers may not have intended it; however this movie is replete with leadership and communication lessons that are applicable to executives, project managers, team members, or any of us especially in difficult times on our projects. You currently may not be in a leadership position but some day may need to lead.  All of us do need to effectively communicate with those that we work with.  You often hear the lament that technical people need to develop “soft skills”. So let’s see what we can learn from Josey Wales and … Read More