People, Processes, and Protection

I'm going to drift a bit from my typical subject matter and talk about the importance of managing people and processes for the protection of all involved.

You may wonder in what context the word protection applies. Protection is the obligation of managers to protect their direct reports, direct reports obligation to protect their manager, and everyone protecting their customers and organization. The glue that holds all of the various protections together is a codified set of processes. I know codification is optional, but to be great instead of mediocre, the processes need to be as well understood and unambiguous as possible thus documentation is required.

Example:

Background: A consulting company has a custom software development effort with their best client. The project is highly visible and the client's financial investment makes it high risk as well. Each two week development cycle has a scoped set of features that the development team commits to and at the end of which results in a demo of the working code to the customer.

Manager Protecting Direct Reports: The development manager works with the development team to scope the features to be developed during the current cycle. Each team member commits to one or more deliverables and provides their estimated level of effort. The development manager is doing his/her best to set up his/her reports to succeed by involving them in the scoping, assignment, and estimation processes.

Direct Reports Protecting the Manager: As the cycle progresses, each developer is cognizant of the commitments to the client and all of them know that no one likes surprises. When a feature is bigger than expected or unforeseen obstacles arise that threaten the ability to deliver the scoped feature(s), the development manager is notified as early as possible to allow him/her to manage expectations with those outside of the team.

All Protecting the Customer and Organization: Because the development team does a good job with making the manager aware of the risks as they become known, the manager can notify the customer as early in the cycle as possible. Once the risks are known they are managed throughout the cycle. This allows the customer contact to manage expectations at their end. A byproduct of being disciplined with this process of protecting the customer results in successful projects and enhancing the reputation of the development team and organization as a whole.

Team Value System

Protection and process is all great but those items don't define what is being protected and why were the processes developed. Before processes can be designed and implemented there needs to be a team value system. The value system consists of the things the team views as important principles that are required to be successful.

There are several steps required to crystallize the team's focus of its value system as well as defining who the team is, where it's going, and how it's going to get there. Each of the steps should align with the organization, cost center, department, team, and individual.

1. Vision and Mission Statements: The team needs to know unambiguously why it exists and where it is going. If you don't have them, then write them. You'll be surprised at how much thinking you'll need to do.

2. Team Value System: A team's value system is essentially the rules of engagement at the individual level. Here is a small example:

• Team First
  
  • We constantly strive for balance of skills throughout the team.
  • There is redundancy within the team, e.g. primary/secondary client contacts.
  • Choosing the right resource for a particular task/project is dependent on:
    
    • Task/Project Context
    • Required Skills
    • Desired career path of team members
• Communication
  
  • We err on the side of over-communication
  • We are collaborative with solving problems
    
  • Conversation is more accurate than written correspondence
• Customer
  
• Everyone is everyone’s customer
• Super-pleasing is the standard level of service

3. Team Composition: This is the act of documenting how your team should be assembled; essentially what is the strategy with regard to the the required skills within the team and how that manifests itself into the types or categories of people needed to most effectively perform day to day activities. I'd suggest categorizing your current team members into each of the types that you identify to see if you are aligned properly.

Protection Through Process
Once the three steps are complete it is time to create the processes that ensure the value system is efficiently implemented on a day to day basis - without significant dependency on human oversight. Heavy involvement by people to ensure the plan is executed daily is inefficient because of the transient nature of people, the periodic unavailability of people, the expense of human oversight, as well as a host of other reasons. Processes need to be developed in a way where, for the most part, the team runs itself. This paradigm is scalable. When specific people leave the organization or become unavailable for periods of time, the processes don't fall apart. It also leaves people more time for innovations that make the processes stronger.

Teams and its members have good intentions that sometimes go awry. In most cases when things don't go as well as expected it is because the team/individuals don't have a clear idea of their value system and/or poor processes that don't protect them. The idea is to consistently put people in a position to win. In my experience, implementing the tools described here help teams be the best that they can be.

I'm interested in you thoughts.

Estimating Probabilities for Delivery (< 10 Tasks)

Delivering an application on the date specified at the beginning of a project is rarely, if ever, achieved; especially if the delivery is expressed as a single date (commitment) instead of a range of dates (estimate). However, there are ways to estimate the probability of delivering on specific dates using relatively simple formulas in just two steps.

Step 1: Calculate the standard deviation for each task
This isn't as scary as it sounds. Here is the formula:

StandardDeviation = (SumOfWorstCaseEstimates - SumOfBestCaseEstimates)/6

Your estimates are based on Worst, Best, and Expected cases, right? I hope so. The denominator (6) in the formula counts as one standard deviation. One standard deviation means that 99.7% of your estimates will fall within the Worst/Best range. Depending on the risks associated with the project or your skill with estimating you may want to decrease the denominator as a buffer. For example, using 2 as the denominator means that 68% of the actual effort per task will fall into the Worst/Best range. Steve McConnell's opinion in his book Software Estimation: Demystifying the Black Art is that accomplishing a 68% accuracy is achievable with practice so you might want to start out using a denominator of 2 or less until your historical data tells you otherwise.

Step 2: Calculate the probabilities for delivery
The next step is to apply the standard deviation to calculate the likelihood of delivery. Below is a table with the probabilities:

Percent Likely	Calculation
2%	Expected case - (2 x StandardDeviation)
10%	Expected case - (1.28 x StandardDeviation)
16%	Expected case - (1 x StandardDeviation)
20%	Expected case - (0.84 x StandardDeviation)
25%	Expected case - (0.67 x StandardDeviation)
30%	Expected case - (0.52 x StandardDeviation)
40%	Expected case - (0.25 x StandardDeviation)
50%	Expected case
60%	Expected case + (0.25 x StandardDeviation)
70%	Expected case + (0.52 x StandardDeviation)
75%	Expected case +(0.67 x StandardDeviation)
80%	Expected case + (0.84x StandardDeviation)
84%	Expected case + (1 x StandardDeviation)
90%	Expected case + (1.28 x StandardDeviation)
98%	Expected case +(2 x StandardDeviation)

There are more complex methods for calculating deliver dates for projects that have greater than 10 tasks. I’ll be writing about those in future articles.

I have a variation of the above in the form of a spreadsheet that I use as a template for inputting tasks with their respective estimates. The spreadsheet will automatically calculate the standard deviation and percent likely delivery dates. If you would like me to send it to you feel free to email me at jack@notarangelo.com and I’ll send it along.

Workflow Patterns

A colleague of mine gave me good advice a while back about blogging. He recommended that I submit articles frequently and that they be short and concise. I'm not sure how proficient I am at writing short and concise articles but my guess is that this one will be the shortest and most concise of those that came before it or will be written after it.

I stumbled across an excellent web site for workflow patterns . The site contains research on workflow patterns conducted by various academicians and are sanctioned by the Worflow Management Coalition. Below are links to the four papers that I think are a must read if you are working with or developing any kind of process-aware software. You can view the content on the web site directly or download a PDF file at the top of each link with all the patterns under that respective category.

Control-Flow Perspective
Data Perspective
Resources Perspective
Exception Handling Perspective

Agile Feedback Loops

One of the most important aspects of Agile is the feedback loop contained in virtually every aspect of the methodology and the built-in efficiencies related to it. I know I'm being Master of the Obvious, but knowing about a problem immediately and thus fixing it immediately is so much easier and manageable than untangling many problems that were unknowingly compiled over the course of months and with a short amount of time to straighten everything out. Aggghh .. it's stressful just thinking about it. Below are the places in the Agile methodology (or at least the way I have implemented it) where we see feedback loops.

Continuous Integration (CI)
When code is checked in, the application will successfully build or it will not. On my team, we get automated emails after the CI process runs regardless of success or failure so feedback is received in both positive and negative outcomes. The rule is - don't leave for the day until your checked-in code successfully builds and the unit tests succeed. When the CI process fails, it is the top priority of the team to fix it.

Nightly Build and Deploy
Every night the projects that make up the application are built and deployed to a distributed environment. During this process the compilation, automated unit tests and automated QA tests should succeed. If anyone of those processes has a failure, then, just like with the CI process, it is the top priority of the team to fix the failure.

Daily Stand-up
Every day the project team meets for 15 minutes where each member tells the their team members what they worked on yesterday, what they are working on today, and what obstacles they have. As a result, missteps in priorities is only a day away from being corrected and information about what someone else is working on that is pertinent to a developer is communicated every morning.

Sprint Retrospective
At the end of every two week sprint, the team discusses what they think went well and what went not so well. This feedback provides the necessary information to tweak our processes accordingly. Little by little our processes gets stronger.

End of Sprint Demo
This is where the rubber meets the road. At the end of every two week sprint we have an immovable demo to the client. What does our customer think about our work? Did we get it right or wrong or a combination? What insight is gained about the application as a whole as a result of this sprint's development and what is the effect on the priorities for future development?

I was in a client demo yesterday for Sprint 12 - thus it was my 12th demo for this particular project with 4 more to go - when I had a somewhat out-of-body experience. As we were nearing the end of the demo where I was peppered with questions by a room of 10+ client stakeholders asking "will it do this? will it do that" of which my response was "well let's see" (and in virtually all cases the app performed well), I mentally became detached from the demo process and saw the entire project life cycle in my minds eye and was stunned.

That's when I said to the group "Can you believe how well this is working? This is amazing." And, that's when they started making fun of me by asking me if I wanted to be carried around the room. By the way, having a demo every two weeks with your customer promotes a positive bonding experience (assuming the demos are successful).

The reason for my impulsive utterance was that after developing software for the better part of the last 15 years (a lot of which was not using Agile), I'm still stunned how well Agile works. Of course you need high quality developers too but the constant feedback loops and addressing issues immediately instead of during UAT is directly related to successfully demo-ing an application 12 times with minimal glitches.