Eventyr

Gender Decline

Carrie Hartnell, private sector programme manager at Intellect, comments: “The continuing drop in the number of women in the IT industry, though an international phenomenon, continues to have serious and far reaching implications for the UK economy and can no longer be regarded as just a diversity issue.

“There are good initiatives but these have clearly not been pervasive enough or resulted in the necessary improvements. As an industry we must begin by tackling the cultural barriers, which have prevented the effective recruitment and retention of women. If this is achieved the presence of women in the high-end sectors of the economy will benefit both the industry and the UK.”

UK IT sector losing women

Another article on the decline of women in IT.  I find it odd that it never occurred to me that there may be a meaningful gender divide, i.e. that there was more to the issue than just a lack of diversity.  The decline is intriguing.  It has certainly piqued my interest into gender in the workplace.

Female Designs

But generally there has been a "massive global failure to address this critical issue", Ms Bernhardt says. "To me the real issue is in the harder IT areas (of) programming and design. We have desperate shortages and a rapidly declining rate of girls taking up studies in this area.

"If more females were involved in designing and creating technology, we may see a world with different designs and one that takes into account an inclusive set of perspectives. We may even see technology that is simpler to use and more attractive. Technology designed without female input can be critically one-dimensional."

IT Women in the industry

Curious thought.

Project Management Notes

"When you work in IT, you deal with the consensual hallucination of Project Management. There is an almost universal belief that it is possible to predict ahead of time how long a project will take, how much it will cost and what will happen along the way. In the broadest sense, this is possible. If you have enough experience you can come up with ballpark figures; last time we did something similar it took this long and cost this much.  But some people believe Project Management should tell you these things down to the day and the dollar. A project plan should tell you every task that needs to be completed. A project plan should be flawless and leave nothing to chance. And a project plan should be completed before ANY work is done on the project."

The Myth of Project Management

----

"Although they are often unappreciated by those around them, they are critical to making software development happen.  The best project managers are often the most inconspicuous since things happen so smoothly when they are involved."

Positive Activities:

1. Manage Customer Expectations
2. Develop a Rapport with the Customer
3. Understand Where the Project Really Is
4. Increase Visibility
5. Speak the Developer’s Language
6. Know How to Say No

6 Signs of Good Software Project Managers (via Tom)

----

The key terms above also fit with arguments over the role of project management in Agile, where the commonly asked question is `Does Agile Dispense with Project Managers?' since they are not expected to 'run' projects:

"Agile methodologies do away with many of the tasks by which Project Managers formerly measured their own performance: they are no longer required to manage the triple constraints of cost, schedule, and scope.  Product Owners and Development Teams are now accountable for these activities. 
So, traditionally trained project managers experiencing the shift to Agile are often confused as to what their new roles and responsibilities should be in an environment that no longer requires them to make stand-alone decisions."

The positive activities detailed above really come into force here.

----

To Manage Agile Projects you need to consider the following suggested practices:

• Emphasizing leadership, not management
• Tackling visibility and reporting
• Prioritizing requirements based on business value
• Making collaboration a first-order process
• Implementing true test-driven development

----

People are still needed (pdf) to:

• Manage the Boundary
• Manage Team Membership
• Manage Risks
• Be a Team Champion

----

There exists A Project Manager's Survival Guide to Going Agile which may provide a useful resource when I get the chance to read it.

Going Agile - APM

Taking an Agile approach to software development for the first time is no small task:  there are a number of different practices to onboard and process change is disruptive, frustrating and potentially demoralizing. How do you onboard Agile practices and still meet delivery requirements? To what extent can these be introduced, especially the first time around, so that they stick?

There are two things to balance when introducing new practices: adopt at a pace that doesn't push too far too fast and simultaneously establish a "critical mass" of core practices to reap symbiotic benefits. While there are no hard-and-fast rules on how or where to begin, the right sequence can increase probability of success and set the stage for greater process adoption.

So You've Decided To "Go Agile" - A Pragmatic Approach To Onboarding Agile Project Management

Potentially the main document I need to think about, and digest, this week I think.

Software Testers

• The love for bugs
• Detectives of the IT world
• We break things because we can
• Testers maintain focus
• Always learning

Characteristics of software testers by Rosie Sherry

Process Facilitator

The term "Process Facilitator" refers to the people in your organization whose primary responsibility lies in improving the effectiveness of the work that the teams are doing. This responsibility is mainly around the process the teams are using, but also encompasses less tangible aspects of work such as team development, organizational culture change, administrative and technical tools, and working with other Process Facilitators both inside and outside of your organization.

In an agile environment, the Process Facilitator has several aspects of expertise and skill to develop, and not all of these can be developed simultaneously:

• Basic Agile Work administrative skills.
• Obstacle removal.
• Team dynamics and development.
• Coaching individuals.
• Organizational development.
• Training groups and teams.
• Promoting agile methods.
• Strategic application of agile methods.

Reward your Process Facilitators as they take on and master each of these areas of skill and knowledge. A Process Facilitator is successful when he or she is able to help a team to become self-sufficient. The team has learned and perfected the basic Agile Work process. The team has gone through the stages of team development (forming, storming, norming and performing) and is now capable of self-directed self-improvement. The organization is no longer resisting the team's efforts to self-organize, to continue learning and to eliminate waste, but rather is fully supportive of these efforts. Once all this happens, the Process Facilitator is no longer necessary as a separate role. The person who has filled this role may then go on to become the Process Facilitator for another team or another part of your organization, or even be loaned out into your supply or customer chain in order to help make those relationships with your organization more effective.

Managing Process Facilitators

Ok, so...  Facilitator.  Not administrator or coordinator. Good to know for future reference. 

Actually, it's really good to know that this exists, and is not a self-created figment.  For now I shall stick with my role as Process Administrator.

More Links:
The Above Article as a PDF
Process Facilitator Cheat Sheet
International Association of Facilitators

Start-up Issues

In a sense there's just one mistake that kills startups: not making something users want. If you make something users want, you'll probably be fine, whatever else you do or don't do. And if you don't make something users want, then you're dead, whatever else you do or don't do. So really this is a list of 18 things that cause startups not to make something users want. Nearly all failure funnels through that.

The 18 mistakes that kill startups (via Kevan)

Notes for later:
Single founder, location, niche, derivative, obstinancy, programmers, platform, launching late or early, no clear user, money and spending, investor management, sacrificing users for profit, not wanting to get hands dirty, fights between founders, half-heartedness.

Project Management

I attended my first ever e-seminar on Thursday. It was an open seminar by the IEEE on How To Become a Successful Project Manager by Margaretha Eriksson. 

Once I got past the networking issues and resigned myself to using LiveMeeting, I found the interaction involved quite engaging.  I do wish the university's roaming network had allowed for a consistent connection.

It was interesting to find out how much of the talk covered management practices with which I was already familiar (mostly around communication and 'team experience').  I'll take this as a good sign, but not enough of a reason to quit my day job.