ScrumMaster Training

Just completed ScrumMaster training through Danube, with Tobias Mayer. First off, Tobias is incredibly gifted in bringing understanding of business drivers, software challenges, and the spectrum of people's strengths and idiosyncracies all into a blend of guidance and assurance of how to really make this work.

My biggest take-away is that Scrum is simple, but it's not easy. And it's better to jump into rough water and try it than to wait for an ideal time and circumstance. From what I could tell from those who had been praacticing it, Scrum takes some courage (absense of self for the sake of the cause) to lead through it.

It is easier to do command-and-control waterfall projects, knowing they're more likely to fail, because the structure makes blaming others for project failure to easy (and often incorrectly) because of visibility on silo'd efforts. When effort in that specific task fails, the owner is more likely blamed because it appeared that required requisite steps were 'completed' and done so correctly (or else the project wouldn't have moved on).

In a scrum, all requirements, programming, project management and QA efforts are occurring simultaneously and you know the outcome in 30 days or less. So, who would you blame in the event of a failure? The whole team was involved. So one would have to look deeper into the causes, and that is always the right thing to do. Also, how severe would the consequences be on, at worst, losing a month's worth of work on a Scrum sprint versus three, six or more months on a waterfall project?

As far as learning Scrum, here are two additional links: The Agile Toolkit podcasts and a list on Amazon called The Scrum Master's Bookshelf.

Time Tracking for Team Member Accountability

As much as I feel strongly about employee motivation and appreciation, I see the accountability and extra effort that comes from employees who have to account for every hour of the day via timesheets (I should add how important that these timesheets are actually reviewed).

I have seen exponentially more effectiveness when an employee realizes that they have to not only account for where their time goes each day, but that there is accountability for how much time is taken for each task and some responsibility for whether that task was the appropriate priority. If there is no consequence for not working, not working hard, or not working on the right things, then what is the motivation to work diligently on the right things? Generally there is no more consequence than “you should have asked me: for more work/if that was the priority/how long I expected that task to take.” If so, every day spent doing what the employee would rather do is its own reward.

I’m seeing now that new employees generally work quite hard in the first week or two, not because the want to impress, but more often they are concerned about consequences for not working hard at the right things. Once they are sure there are none, they quickly adjust to the acceptable (palatable) pace of those around them.

Think of the additional gains of a time tracking system: real time actual costs of projects, estimates-to-actuals by project, team size, team members, real bell curves of resource usage in order to intelligently schedule overlapping projects.

Project Areas and Team Member Proximity

I’ve seen significant increase in information sharing on project teams due simply to having daily scrums (agile status meetings). I’ve wondered how much more would communication (and therefore team performance) improve if I had the team members moved to cubes in the same area. The evidence from Tom Peters, below, is significant. Note how close teammates need to sit for optimal interaction.

“…if you and I are separated by 5 yards or less, the odds of us communicating at least once a week are nearly 100%. At 10 yards of separation, the odds plummet to about 9%; and said odds are almost constant at 3% if we're 30 to 100 yards apart.”

Quote referenced from Tom Peters’ weblog here.

Proactive with Dependencies

I use the Getting Things Done Outlook Add-In from NetCentrics (http://gtdsupport.netcentrics.com/learn/ ) for time management and I depend on it for project management because it allows me to set email reminders for follow-up email interactions with other team members I require a response from, especially the sometimes goal-disconnected client team members because they are not in our office.

A tool I would like to have in order to be proactive about dependencies is a network resource monitor. In consulting, too often we have tasks that we get tripped up because someone changed something on us without notifying us. When it comes time to perform the task, we find that we have lost privileges to the client’s VPN, or SQL Admin rights to a database or local machine admin privileges on a test server. The delay in getting these resolved can impact deadlines.

If I could set up a monitor app to check these resources, using accounts the client has given us, I could know immediately when access has changed. I could then quickly put in a request to resolve it, and have the problem worked in parallel and fixed before it impacts project deadlines down the line.

If anyone knows of an application that can do this, please let me know.

Pacing Scrums

A client recently asked that I change our project management so that we run our one month scrum, then stop development activity. The pause was to allow the team to be available to help with support and user adoption, asses, then determine what to take from the product back log and begin the next sprint.

It’s easy to move faster than the user community, and if several dozen new features and functionality pile up without adoption, the result is that it is quite possible the real objective has not been met. I like this idea of scrum 'pacing', although it makes planning staffing more challenging.

IT Manager's Survey

I've been conducting an IT Manager's survey. I'll be using the results of as part of an effort to understand how personality and natural talent can be leveraged to improve one's career. The responses will be aggregated with the answers from other managers, and I'll post the final results here sometime in the futre.

I was previously a supervisor of a development team, and have my opinions on how developers can improve themselves and their career, but I want make sure I accurately represent the breadth of IT managers. The responses from other managers will help ensure this. Below is the survey.

Manager's Survey


1. What vehicle do you prefer for candidate leads?
A. referrals
B. job posting and interviews
C. recruiters and interviews
D. Other:

2. On the range of 1 to 5, with 0 being no experience with a technology and 5 being significant production-level experience, what significance would you give a interviewee if they had used the technology you're looking for a prototype at work, working demo or test application at home?
A. 5 - Equally significant. Understanding the technology can is the same whether done as part of a complex production or a working demo on a dev machine.
B. 4 - Significant. Of considerable value.
C. 3 - Minimally significant. Of little value.
D. 2 - Somewhat insignificant. Of almost no value.
C. 1 - Insignificant. Making a demo or test application is of no value in getting experience of applicable worth.

3. If a candidate had a blog, would you read it? Would a blog factor into requesting an interview or your evaluation of candidate ability and match for the position?
A. 5 - Very significant factor. I would take time to read the blog and give them equal weight with the resume.
B. 4 - Significant factor. Glad the candidate is sharing their knowledge and views. I would likely review some or most of the blog.
C. 3 - Not really a factor. Good for them that they're blogging, but I most likely would not even go to the blog.
D. 2 - Somewhat insignificant factor. Of almost no value. I would not go to the blog.
C. 1 - Insignificant. I couldn't care less that the candidate has a blog.

4. Besides technical skills and previous positions, what traits do you look for in a job candidate?
Please mark no more than 4.
self-starter works well independently team player
good communicator problem solver innovative
dependable calm leader
energetic organized creative
follows directions works well without structure Other:

5. Describe the attitude of your best employee. What does he/she do?


6. If you could have your typical developer change or grow in some way, what would it be?


7. What's your most common complaint, problem with a developer?


8. What do you look for when you have an opportunity to promote someone?


9. Describe one of the best workers you've recently (or still) have.


10. Describe one of the worst workers you've recently (or still) have.


11. What would you recommended to a programmer (or other IT worker) looking to advance in his career?


12. Could you list three to five basic traits, skills, or talents (such as strategic, responsible, decisive, persuasive, high achiever, adaptable, disciplined, quick learner, positive, or any others you choose) that define or describe the following roles:
- Senior:
- Architect:
- Lead:
- Supervisor/Manager:



13. Have you read about or been involved in training regarding personality styles, temperaments, traits, or strengths, and if so, what was the material or organization?


14. How did you get into your current position?
A. Hired into the position from another company where I was a manager/supervisor
B. Hired into the position from another company where I had a leadership role
C. Hired into the position from another company where I did not have a management or leadership role
D. Transferred within the same company into the position from another group where I was a manager/supervisor
E. Transferred within the same company into the position from another group where I had a leadership role
F. Transferred within the same company into the position from another group where I did not have a management or leadership role
G. Promoted within the same team
H. Other:

Spolsky's Guerilla Guide to Interviewing

I've been reading the chapter on interviewing from Joel Spolsky's Joel on Software (2005 Jolt Productivity Award winner). Two points that floored me, but I had to admit rang true.

First, there's only two qualities to look for in candidates:

1. Smart
2. Gets things done

Spolsky clarifies "smart" not as "knows a lot of facts" such as the "What's the difference between VARCHAR and VARCHAR2 in Oracle8i", but aptitude - the ability to learn quickly, easily.

I'll also add that the reality is that the paradigm of programming knowledge has changed over the last 6+ years. Before the internet boom, the ability to learn and hold details (such as syntax) was valuable because it took time to find information in a book or ask a coworker (stopping his flow). Now, it takes seconds to find answers. The value is now on the ability to search effectively and know enough about concepts to help set the context of your search and what you actually need.

Secondly, in the interview, ask open-ended questions that allow you to see three key attributes:

1. Passion
2. Ability to explain things well
3. Signs of leadership

Personally, I see these three as qualities that cannot be coached or taught effectively.

Add these items to other areas in business where we should First, Break All the Rules.

My Strengths According to Gallup

Per the Gallup Organization's Web-based talent assessment tool StrengthsFinder. When you purchase "Now, Discover Your Strengths" by Marcus Buckingham, you are provided with a key to take the exam online.

Per StrengthsFinder, my top five strengths are:

Strategic: People strong in the Strategic theme create alternative ways to proceed. Faced with any given scenario, they can quickly spot the relevant patterns and issues.

Input: People strong in the Input theme have a craving to know more. Often they like to collect and archive all kinds of information.

Learner: People strong in the Learner theme have a great desire to learn and want to continuously improve. In particular, the process of learning, rather than the outcome, excites them.

Responsibility: People strong in the Responsibility theme take psychological ownership of what they say they will do. They are committed to stable values such as honesty and loyalty.

Arranger: People strong in the Arranger theme can organize, but they also have a flexibility that complements this ability. They like to figure out how all of the pieces and resources can be arranged for maximum
productivity.

I have had several of my staff take the exam as well. Not only are we finding that the results are incredibly accurate, but the seeing strengths of my team so clearly has helped me to adjust the work so that they are fulfilled, challenged, better utilized and more productive.

Which Project Management Approach Is Best?

I've been studying the Guide to the Project Management Body of Knowledge (PMBOK) lately, in preparation for the Project Management Institute's Certified Associate in Project Management credential (CAPM®) . I had recently read Craig Larman's book Agile and Iterative Development: A Manager's Guide. Reading about so many benefits of being agile and incremental in project approach, I would have said my project management preference was agile.

Now that I'm reading the PMBOK, I'm finding that there is a lot of value in the process-heavy PMI PMBOK. I say process heavy because, for starters, there are over 20 process steps in the Planning Process - one of five core processes. Each of those process steps can have several input and output artifacts. The value I'm finding is that, per the PMI's decades of effort towards a comprehensive project management guide, if I know their framework I shouldn't miss any steps in the next project I work on. I say framework because the PMBOK itself says that the steps are optional, and should serve indeed only as a guide. So, take what works and leave the rest.

One fear I have is that perhaps some say 'go agile' partly because it is easier to digest and understand in your head. But if someone doesn't understand all the possible steps they should take, they will miss the times when some extra process step would have saved the project at a critical juncture. Like any software framework, the PMBOK is a structure, guide and set of optional tools, but the benefit is in knowing what it is and therefore what you can apply where. Agile, in part, means low ceremony and therefore just enough process and documentation to deliver a quality product that meets the customer's needs and expectations. In my opinion, Agile and the PMI are not mutually exclusive. Not only that, it seems apparent that smaller, less defined, lower risk projects would benefit from an agile approach, while a large, multi-disciplinary, high-risk project woould be best suited following the PMBOK's process tightly. And odd as it sounds, I'm studying the PMBOK while starting my second agile project management book (Agile Project Management : Creating Innovative Products).

Perhaps its human nature, but I'm finding some tendency to polarize. I've worked with developers who felt that client-server was old and bad, and that, web development was the obvious direction to go, but there's a right time and scenario for each. I think people like precut answers, and veer away from answers like "well, that depends.."

So, what project mgmt approach is the best? Well, that depends...

Stay Lean

From Nuts! Southwest Airlines Crazy Recipe for Business and Personal Success regarding staying lean:

Bureaucracy creates a mindset of dependency, which makes people do what they are told but no more. Rather than encouraging employees to assume ownership and responsibility, bureaucracy teaches them to transfer responsibility. Leanness, on the other hand, gives control, ownership, and responsibility to those who are closest to the action. Southwest allows its people a lot of decision-making power and authority. With no more than four layers of management between a front-line supervisor and Herb Kelleher [CEO], the leader's span of control is very broad at Southwest.

Kelleher believes that excessive bureaucracy results from the egos of empire builders who try, through title and position, to emphasize their own importance.

In a bureaucracy it's easy for an employee to say "that's not my job." This undermines productivity and prevents the company from being as nimble and moving as quickly as it might. Leanness helps identify nonperformers because,in a lean organization, marginal performance is difficult to hide.