Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Tech lay offs hit 3 year high: The case for agility and project leadership!
| The employment landscape for technical jobs does not seem to have come even close to hitting bottom. This report from CNET indicates that lay offs in the tech sector will hit a 3 year high.
As the report states:
During the first half of the year, 51,529 planned job cuts were announced across the tech sector, representing a 260 percent increase over the 14,308 layoffs planned during the first half of 2011. Things are so bad so far this year that the figure is 39 percent higher than all the job cuts recorded in the tech sector last year.
Hewlett-Packard proved to be the major force behind this year's uptick in planned layoffs, after the company announced in May that it would cut 30,000 jobs. Those layoffs will be completed by the end of fiscal 2014, and shave off 8 percent of HP's entire workforce.
It was also a tough beginning of the year for Sony and Nokia, both of which said they would lay off 10,000 employees. Panasonic and Olympus are also eyeing layoffs to make their operations more nimble.
About 60% of these cuts were due to the massive job lay offs anticipated by HP which has been unable to turn around their PC centric business model to the ever growing tablet and smartphone market that has taken the world by storm. To me this makes the case of adopting more agility and project leadership into your repertoire of transferable skillsets if you are in the IT/Tech sector as I'm sure many on this site are. HP itself could have been more agile and leading more profitable and innovative projects as well!
More troubling is this graph generated from the US Dept of Labor Statistics for jobs related to "information services" the majority of which were IT services:
This was generated based on the aggregate data of the last two decades starting from June of 1992 to June of 2012. The graph highlights the peak hit during the late 90s and early 2000 during the dot com rush and reveals the continuous downward trend to near 1992 levels!
Sorry to be so doom and gloom, but if like me you are in the IT/Tech sector, then its time to assess your talents, practices and skillsets and think how you will adapt, be agile and lead projects of the future. I know I will!
During the first half of the year, 51,529 planned job cuts were announced across the tech sector, representing a 260 percent increase over the 14,308 layoffs planned during the first half of 2011. Things are so bad so far this year that the figure is 39 percent higher than all the job cuts recorded in the tech sector last year.
Hewlett-Packard proved to be the major force behind this year's uptick in planned layoffs, after the company announced in May that it would cut 30,000 jobs. Those layoffs will be completed by the end of fiscal 2014, and shave off 8 percent of HP's entire workforce.
It was also a tough beginning of the year for Sony and Nokia, both of which said they would lay off 10,000 employees. Panasonic and Olympus are also eyeing layoffs to make their operations more nimble.
|
Posted on: July 23, 2012 11:06 PM
| Permalink |
Comments (1)
Agile Constraints
| Projects whether they are done Agile, waterfall, extreme, or whatever [insert favorite practice here], boil down to a series of interconnected tasks that require you to manage and reduce the variations between them to make sure they are done on time and within budget. Often times what prevents you from reducing the variations are constraints. In other words, some bottleneck is constraining you from reaching your optimal throughput.
This type of thinking lies at the core of the “Theory of Constraints” which originated and was made popular by Eliyahu M. Goldratt in his very popular business novel “The Goal”. TOC’s approaches constraints from an overall systems view and does not concern itself with every individual task, but rather how to maximize the overall system. So you have to recognize that your project’s total throughput will be the equivalent of your bottleneck. This requires you to focus on five steps to remove your bottlenecks:
If I were to view this from a Agile/Lean perspective, I should be able to quickly find the bottleneck (I think this is very similar if not the same as Scrum’s notion of an impediment), since this is where the story cards start to stack up. Typically in software development projects where Agile is done the most, the usual bottlenecks are in QA if you do not have much automation in your testing since there can be idle time before finishing a story before having it tested.
And sure enough, others in the Agile community have made use of the manufacturing technique known as Kanban. This technique sets up a WIP limit to the most important columns on the board and is where you should find where things like testing are hitting their WIP limits frequently. This is where you could take other resources that are sitting idle to assist the testers and since you’re doing Agile, you teams should be cross functional and be able to pick up the slack. At some point the “flow” would resume.
This is a very interesting integration of various techniques to remove bottlenecks in your projects. How are you dealing with constraints in your projects?
But sure enough, the solution other’s have found is to use Kanban since it sets up a WIP limit to the most important columns on the board and is where you should find where things like testing are hitting their WIP limits frequently. This is where you could take other resources that are sitting idle to assist the testers and since you’re doing Agile, you teams should be cross functional and be able to pick up the slack. At some point the “flow” would resume.Projects whether they are done Agile, waterfall, extreme, or whatever [insert favorite practice here], boil down to a series of interconnected tasks that require you to manage and reduce the variations between them to make sure they are done on time and within budget. Often times what prevents you from reducing the variations are constraints. In other words, some
bottleneck is constraining you from reaching your optimal throughput.
This type of thinking lies at the core of the “Theory of Constraints” which originated and was made popular by Eliyahu M. Goldratt in his very popular business novel “The Goal”. TOC’s approach is from a overall systems view and does not concern itself with every individual task, but rather how to maximize the overall system. So you have to recognize that your project’s total throughput will be the equivalent of your bottleneck. This requires you to focus on five steps to remove your bottleneck:
Locate the bottleneck
Maximally exploit the bottleneck
Subordinate everything else to exploiting the bottleneck
Elevate the bottleneck (add capacity some other way)
Avoid inertia and keep checking your bottleneck hasn't moved
If I were to view this from a Agile/Lean perspective, I should be able to quickly find the bottleneck (I think this is very similar if not the same as Scrum’s notion of an impediment), since this is where the story cards start to stack up. Typically in software development projects where Agile is done the most, the usual bottlenecks are in QA if you do not have much automation in your testing since there can be idle time before finishing a story before having it tested.
But sure enough, the solution other’s have found is to use Kanban since it sets up a WIP limit to the most important columns on the board and is where you should find where things like testing are hitting their WIP limits frequently. This is where you could take other resources that are sitting idle to assist the testers and since you’re doing Agile, you teams should be cross functional and be able to pick up the slack. At some point the “flow” would resume.
|
Posted on: July 17, 2012 11:42 PM
| Permalink |
Comments (1)
Scrum baby, scrum!
| In line with last month’s theme of personal project management, I found this interesting post on using Scrum for the planning and managing of the arrival of a new baby. Here’s a great snapshot of the makeshift tasks board used for the planning, prioritizing and tracking of tasks: 
I leave it to the reader to go visit the site for the details of how Scrum was used that is both lively, detailed and entertaining.
Are you being Agile on your own personal projects?
Just goes to show how useful PM methods and techniques can be when applied to real world (and this is as real world as it gets!) situations and events.In line with last month’s theme of personal project management, I found this interesting post on using Scrum for the planning and managing of the arrival of a new baby. Here’s a great snapshot of the makeshift tasks board used for the planning, prioritizing and tracking of tasks:
I leave it to the reader to go visit the site for the details of how Scrum was used that is both lively, detailed and entertaining.
Just goes to show how useful PM methods and techniques can be when applied to real world (and this is as real world as it gets!) situations and events.
|
Posted on: July 02, 2012 08:53 PM
| Permalink |
Comments (1)
Teams that are “self-appraising”
| 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:
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
| 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:
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)