Project Management

Agility and Project Leadership

by
A contrarian and provocative blog that goes beyond the traditional over-hyped dogma of "Agile", so as to obtain true agility and project leadership through a process of philosophical reflection.

About this Blog

RSS

Recent Posts

Has Scrum outlived its usefulness? Should Scrum just go away?

The rise of Agile’s SAFe is like a bad episode of the movie Groundhog Day

Marcel Proust’s recursive novel: Why the concept of iteration in Agile is shortsighted

Forecast for 2015: The beginning of the end of Agile?

Google considered the best US company to work for due to HR agility

Categories

Date

Teams that are “self-appraising”

linkedin twitter facebook Request to reuse this  

As the mid-year rolls around for all of us, if you are part of a large organization this is typically the time a mid-year performance appraisal and evaluation takes place for the majority of you.  These annual to bi-annual performance appraisals are are a stressful event for both the evaluator and evaluatee since it determines your ability to obtain bonuses, merit increases, promotions and in the worst situation, whether you will keep your job or not.

But how does this work for Agile/Scrum teams where team members are self-organizing, which implies the ability to harmonize and work together as a collective rather than relying on individual performance, to deliver those working deliverables at the end of each iteration?

An article on the Scrum Alliance website by Uday Shete addresses this very issue quite well, for he states:
 
We can leverage the spirit of Agile to empower the team to appraise its own team members. The sprint retrospective is done continuously, and it helps evolve and improve team productivity and efficiency. The team determines what was good, bad, and ugly, and it determines what it needs to do to improve. Ideal sprint retrospective meetings are conducted within a candid, honest, and constructive environment. What better platform to appraise individual performance as well? Wouldn't every team member appreciate such an environment for his or her appraisal? Since the sprint retrospective is a time-boxed meeting, my proposal is to use 15 minutes out of this meeting for the purpose of individual team member appraisals.
 
Now we have the right platform, with the right people. The team believes it is the owner of the appraisal process and is empowered to carry it out.
 
He outlines a game that can be played by each team member that anonymously discloses whom them felt was the best performer on the team.  The ScrumMaster then holds a 15 minute appraisal session during the retrospective whereby each team member justifies their choice and notes what they could do to make themselves achieve those goals.  This is similar to the Delphi method used in traditional project management to best assess risk by having experts anonymously post and review their opinions.
 
This is not a bad way to incorporate performance appraisals into your Agile agenda and doing so does aligns with the Agile framework as Uday outlines:
  • Feedback is crystal clear and focused on individuals rather than the process.
  • The method focuses on measurable performance, not excessive documentation of an individual's performance.
  • It eliminates negotiation and propagates transparency in the system.
  • It offers quick and frequent feedback, with frequent opportunities to take corrective action.
  • It offers an environment of trust and honesty, which supports the development of the team.
I do agree with a commenter that though this is an effective technique, for most situations it is inevitable that at some point there will be a need for a formal performance appraisal.  These appraisal will also delve into areas such as career goals, individual areas of improvement and other behavioral improvements that can only be shared between the manager, team member and HR that may be in conflict and even contradiction to the teams self-appraisal sessions that can add a layer of unecessary complexity. 
 
Nonetheless, an interesting idea that I think is worth looking into.
Posted on: June 28, 2012 10:50 PM | Permalink | Comments (3)

You actually have to “stand-up” in a stand-up meeting

linkedin twitter facebook Request to reuse this  

The daily stand-up meeting is one of the most famous and important ideas behind Scrum, since this is the mechanism that allows structured communications and work alignments between team members.  It has become such an infamous notion that I ran across an article on the Wall Street Journal talking about this.  The title of the article is “No More Angling for the Best Seat; More Meetings Are Stand-Up Jobs” and it describes how various software firms around the US are utilizing the daily stand-up meeting:

 
The current wave of stand-up meeting is being fueled by the growing use of "Agile," an approach to software development, crystallized in a manifesto published by 17 software professionals in 2001. The method calls for compressing development projects into short pieces. It also involves daily stand-up meetings where participants are supposed to quickly update their peers with three things: What they have done since yesterday's meeting; what they are doing today; and any obstacles that stand in the way of getting work done.
 
If employees are late to this meeting, often called a "daily scrum," they sometimes must sing a song like "I'm a Little Teapot," do a lap around the office building or pay a small fine, says Mike Cohn, president of Mountain Goat Software, Lafayette, Colo., an Agile consultant and trainer. If someone is rambling on for too long, an employee may hold up a rubber rat indicating it is time to move on. Companies make exceptions to their no-sitting rules if a worker is sick, injured or pregnant—but usually not for workers outside the office telecommuting on Skype...
 
As Agile has become more widely adopted, stand-ups have spread along with it. VersionOne, which makes Agile-development software, polled 6,042 tech employees around the world in a 2011 survey and found that 78% held daily stand-up meetings.
 
I think one of the most important aspect of the daily stand-up meetings are that people are actually physically standing up during meetings and are in one room!
 
 
I know it sounds so obvious, but I’ve been part of supposedly Agile/Scrum daily stand-up meetings where people were seated being distracted by their laptops, smart phones, etc. while the rest of the people were dailed into a conference call bridge.  This made for sub-optimal meetings and definitely not what is in the spirit of Scrum’s daily stand-up meetings.
 
Some other things to keep in mind:
  • A stand-up meeting is not a status meeting, but rather actionable items based on what was done, what needs to be done, and what is (possibly) getting in the way.  Your job as Scrum Master is to ensure it stays in this direction and that you commit to removing the impediments.
  • Don’t allow teams to stray into technical minutiae as that will eat up time and distract or bore other team members.  Park those items for later follow ups and make sure only the technical SMEs are involved
  • Make sure the Product Owner is there to answer any questions regarding requirements and backlog items
  • As Scrum Master, keep a list of impediments that is prioritized on criticality and be able to speak to the status of them at any time
  • Try to have the meetings at the same time and ensure that all team members remain till the end of the meeting.
  • If the ScrumMaster and/or the Product Owner cannot attend, keep the meeting anyway to maintain communication, consistency and discipline (again, just because Agile is flexible does not mean it is not disciplined!)
Some guidelines to think about to make stand-up meetings as efficient AND effective as possible, since this is the vehicle that will set the tone for the entire Sprint and help to ensure the team understands how things are progressing and are on the right track for success.
Some guidelines to think about to make stand-up meetings as efficient AND effective as possible, since this is the vehicle that will set the tone for the entire Sprint and help to ensure the team understands how things are progressing and are on the right track for success.The daily stand-up meeting is one of the most famous and important ideas behind Scrum, since this is the mechanism that allows structured communications and work alignments between team members.  It has become such an infamous notion that I ran across an article on the Wall Street Journal talking about this.  The title of the article is “No More Angling for the Best Seat; More Meetings Are Stand-Up Jobs” and it describes how various software firms around the US are utilizing the daily stand-up meeting:
 
The current wave of stand-up meeting is being fueled by the growing use of "Agile," an approach to software development, crystallized in a manifesto published by 17 software professionals in 2001. The method calls for compressing development projects into short pieces. It also involves daily stand-up meetings where participants are supposed to quickly update their peers with three things: What they have done since yesterday's meeting; what they are doing today; and any obstacles that stand in the way of getting work done.
 
If employees are late to this meeting, often called a "daily scrum," they sometimes must sing a song like "I'm a Little Teapot," do a lap around the office building or pay a small fine, says Mike Cohn, president of Mountain Goat Software, Lafayette, Colo., an Agile consultant and trainer. If someone is rambling on for too long, an employee may hold up a rubber rat indicating it is time to move on. Companies make exceptions to their no-sitting rules if a worker is sick, injured or pregnant—but usually not for workers outside the office telecommuting on Skype...
 
As Agile has become more widely adopted, stand-ups have spread along with it. VersionOne, which makes Agile-development software, polled 6,042 tech employees around the world in a 2011 survey and found that 78% held daily stand-up meetings.
 
I think one of the most important aspect of the daily stand-up meetings are that people are actually physically standing up during meetings and are in one room!
 
[insert photo]
 
I know it sounds so obvious, but I’ve been part of supposedly Agile/Scrum daily stand-up meetings where people were seated being distracted by their laptops, smart phones, etc. while the rest of the people were dailed into a conference call bridge.  This made for sub-optimal meetings and definitely not what is in the spirit of Scrum’s daily stand-up meetings.
 
Some other things to keep in mind:
 
A stand-up meeting is not a status meeting, but rather actionable items based on what was done, what needs to be done, and what is (possibly) getting in the way.  Your job as Scrum Master is to ensure it stays in this direction and that you commit to removing the impediments.
Don’t allow teams to stray into technical minutiae as that will eat up time and distract or bore other team members.  Park those items for later follow ups and make sure only the technical SMEs are involved
Make sure the Product Owner is there to answer any questions regarding requirements and backlog items
As Scrum Master, keep a list of impediments that is prioritized on criticality and be able to speak to the status of them at any time
Try to have the meetings at the same time and ensure that all team members remain till the end of the meeting.
If the ScrumMaster and/or the Product Owner cannot attend, keep the meeting anyway to maintain communication, consistency and discipline (again, just because Agile is flexible does not mean it is not disciplined!)
 
Some guidelines to think about to make stand-up meetings as efficient AND effective as possible, since this is the vehicle that will set the tone for the entire Sprint and help to ensure the team understands how things are progressing and are on the right track for success.
Posted on: June 28, 2012 10:46 PM | Permalink | Comments (4)

GE going Agile?

linkedin twitter facebook Request to reuse this  

Saw this post on Wall Street Journal about GE going more Agile.  It states that GE: 

Started down this path several years ago and IT organizations within various divisions are making the transition to this approach at different rates...  this methodology let the IT department complete a project around business analytics for the finance department, from start to finish, in a year, far less than the 18-24 month time frame its consultants and vendors would have taken using a more conventional approach.

The goal of the project was to make it easier to slice and dice financial information so that executives would have better information with which to make decisions. The project involved taking information from different systems and making sure the data could be read by the new software. The team also worked with partners in finance to determine their needs, and included review and testing phases to make sure the software was giving accurate results.

It goes on to elaborate how GE held internal conferences with big name Agile industry gurus as well as hiring Rally software to consult for them on the Agile transition.  Interestingly and telling, was a comment left on the article by a reader who states that GE Healthcare is hardly Agile as it proclaims:

GE Healthcare leadership may proclaim that they are adopting Agile development methodologies, but this is certainly not the case in the Healthcare IT division that builds software for hospitals and physicians.
 
Projects are still required to meet “technical feasibility,” which allows the company to spread development expenses over several years. Unfortunately, this means that 100% of the detailed technical design has to be completed at the beginning of the program before any work can be done. This design can not be changed.
 
In this environment, if a customer’s needs change immediately after “technical feasibility,” the product design is not allowed to change to accommodate this new information. Basically, the needs of Accountants take priority over the needs of the customer and the judgment of the product developers. Not surprisingly, this results in commercially unsuccessful products that don’t meet customer needs.
 
It is difficult to build successful and innovative products when a bureaucratic culture makes it so difficult to respond to the needs of the marketplace.
 
My feeling is that the truth lies somewhere in between the two claims, though I do lean towards the comment left by the reader as being more truthful.  I say this because in the companies I've been involved in, Agile is usually practiced in name only.  This is especially the case with large strong marix and/or functional based companies such as GE.
 
If your in this type of situation, the best advice I could give is to see if you are following at least a few of these principles:
  1. Working more interatively and incrementally, rather than trying to define everything upfront then executing all the work at once
  2. Adopt a way to continually improve the quality of your processes and deliverables
  3. Being more transparent to help clear problems more quickly
  4. Your stakeholders may claim that every requirement is a high priority, but only a few are actually are and you get someone to work with them to get the top priority items done first
  5. Change is inevitable so you plan and execute in iterations cycles that can both accomodate the changes yet still stick to the overall plan

I think if you're doing at least a few of the principles above regulary, you can claim to be on your way to true Agility.  What are you doing to become more Agile?

Iterative incremental
work tends to be more effective than massively detailed plans.
Clean up after yourself continously.
High visibility helps clear problems quickly.
There is always only one top priority: your biggest bottleneck
GE Healthcare leadership may proclaim that they are adopting Agile development methodologies, but this is certainly not the case in the Healthcare IT division that builds software for hospitals and physicians.
 
Projects are still required to meet “technical feasibility,” which allows the company to spread development expenses over several years. Unfortunately, this means that 100% of the detailed technical design has to be completed at the beginning of the program before any work can be done. This design can not be changed.
 
In this environment, if a customer’s needs change immediately after “technical feasibility,” the product design is not allowed to change to accommodate this new information. Basically, the needs of Accountants take priority over the needs of the customer and the judgment of the product developers. Not surprisingly, this results in commercially unsuccessful products that don’t meet customer needs.
 
It is difficult to build successful and innovative products when a bureaucratic culture makes it so difficult to respond to the needs of the marketplace.
Posted on: June 11, 2012 01:00 AM | Permalink | Comments (4)

PMXPO 2012 Agile Q&A Recap

linkedin twitter facebook Request to reuse this  

For those who attended my presentation on “Managing Agility: Embracing the Benefits of Agile Leadership” at the PMXPO 2012, I want to thank you again for attending and Gantthead for the opportunity.  Unfortunately there was not enough time to answer all the questions that came in and there were quite a bit of them: 37 to be exact (question directly asking me about Agile specifics), which is quite a bit considering the majority of them came in after the presentation during the last 20 minutes!

Fortunately though, Erin DeCaprio the fabulous Gantthead MC, provided me the questions and contacts and I will answer all of them directly.  What I’d like to do here is to summarize, categorize and evaluate the questions, as I feel it really reveals the concerns of real world PMs working out there in the trenches like myself and how we go about integrating and leading Agile project initiatives.

Here’s the breakdown from the highest to the lowest:

Area Questions Explanation
Integration 13 These are questions related to how to integrate Agile practices in a traditional PM based organization as well as integrate Agile in domains outside software development.
Process 10 These questions were related to Agile processes such as how to manage Agile projects where there was very minimal documentation, how to estimate tasks/iterations, identify risks and mitigate them, etc.  The main concern was the perception that Agile discourages documentation.
Leader 5 Question asking how to lead virtual teams, how do tools enhance or negate the role of Agile leader, how to lead in a world that is changing so rapidly due to technology innovations (cloud, social media, mobile, etc.).
ACP 5 These questions were about whether the ACP exam will replace the PMP, is the PMP now “obsolete”, question about how to apply experience and whether to take this or get the ScrumMaster.
Adoption 2 Questions about how to get executive buy in and support, training and coaching for organizations looking to move to Agile to increase adoption.
Setup 1 Questions about what kind of tools, training, coaching would be recommended for those looking to setup an optimal Agile environment.
Tool 1 What is the best tool for Agile project management?
     
Total 37  

Though this is a small sample and was not based on a formal survey and anecdotal, as a fellow PM working in a traditional PM environment I can assert that these are my very own concerns and the same concerns of other PMs I work with and know!

I work in the medical device industry that has heavy regulatory and compliance checkpoints that overshadow all the projects I’m involved with that is not always conducive or easy to just “throw” Agile at something to make it turn around faster.

But like every other industry out there these days, there still a need to turn products and services around faster and keep up with the pace of technological innovations, hence an imperative to be more Agile.

In any event, I will answer questions directly to the respondents and as a regular writer on this excellent site, I have lots of topics to focus on since I have a much better idea of what concerns the Gantthead user base.

Posted on: May 25, 2012 01:33 PM | Permalink | Comments (0)

Yet another IT PM certification poll...

linkedin twitter facebook Request to reuse this  

Just saw the results of this survey poll on LinkedIn that I participated in:

  

Not surprised that PMI leads the way, but was a bit surprised by how much.  I really liked the age and demographic breakdown.

Was surpised how low the ScrumMaster certification ranked in this survey, but I think that has to do with the fact that the barrier to entry is so low (you only need to attend a 2 day seminar and once completed you are a certified ScrumMaster).

As I mentioned in another blog, I think we'll see the PMI adoption go higher with the recent explosive growth of the PMI-ACP certification within PMI.  I recently found this graphic showing the growth of the PMP:

Love them or hate them, no doubt when it comes to project management certifications, PMI is dominating the standards and leading the industry to a near monopoly especially in the US with growth in the rest of the world following.

As a commenter posted, "in terms of popularity, PMP would take the lead.....however, if a Project Manager does not how to implement the PMP processes in your working project environment, just 'knowing' the terminology either from PMP or PRINCE2 will not matter...."

I wholeheartedly agree, but if your going to get certified, the best direction seems to be the PMI-way.

Posted on: May 17, 2012 10:17 AM | Permalink | Comments (0)
ADVERTISEMENTS

"How can you govern a country which has 246 varieties of cheese?"

- Charles DeGaulle

ADVERTISEMENT

Sponsors