Ramblings on Peer Collaborations September 27, 2015Posted by Edwin Ritter in Project Management.
Tags: agile, collaboration, peer, peer programming
add a comment
If you had the choice to work alongside someone or work alone, which would prefer? I know, the default answer is “it depends”. What if your experience was more agile team based or some collaborative approach with peers rather than working alone? What your answer be different?
In the increasingly Agile world, peer collaboration to deliver specific tasks will become more popular going forward. With one person being the driver that focuses on the tactics, the observer or navigator can focus on the big picture and strategic aspects.
This approach not only applies to programming – it can be used in multiple parts of the organization. Examples include : finance, purchasing, engineering, sales and project management.
A brief overview of the Pair Programming technique includes:
- Start with a reasonably well-defined task before you sit down. A key part of the process is to get common understanding of current state and what the impact is with the task you will be working on. I also submit this includes support and debug (in whatever form that is) responsibilities after delivery.
- Agree on one tiny goal at a time Keep it simple – Define the approach, ensure you understand the task. This can be a visual of the workflow, a verbal review of the steps and/or a formal write up posted to a common repository. Agree on the best mechanism that works best with your partner and you to complete your goal. As you define the goal(s), you will find that you will…
- Rely on your partner, support your partner. A major benefit in this approach is to tap into your partners’ expertise. Also, your experience and expertise can compliment your partner.Stay committed and focused on the task at hand. When you have a partner with different skills, here is where working together pays off. Together, you both are smarter than when working alone. Use that to your advantage to define a solution and improve it when you….
- Talk a lot! Think out loud and often. In the early stages, you need to get the ‘creative juices’ going. Bouncing ideas off each other helps to sort out what is and is not feasible to solve the task at hand.
- Sync up frequently. Avoid dominating the conversation and direction. Get feedback, ask questions and confirm you both have a common understanding. Work both the tactical and strategic levels and ensure agreement.
- Take a moment to celebrate as you complete tasks and overcome problems. Victories are always short lived – All too often, being successful gets overlooked. Take a moment to bask in the glow of your accomplishments. You probably learned a bit about yourself and your collaborator as well. Feel better? Good. Now, get back at it!
- Switch roles often—at least every half hour. Related to the driver and observer. As a guideline, switching on that interval may or may not be possible. Define a reasonable interval works for you both and then adhere to it. This may take some time initially to sort what works best. It may also impact office hours and the time commitment you both are willing to make for this effort.
I have use this approach with success in the past working with peer project managers. I understand the hesitation by management to use this approach and to be successful. Collaborating requires a higher level of trust and commitment up and across the organization. By definition, collaborating is a more social way of working that combines strengths and can reduce development cycles. The result is a better work product with fewer defects and delivered in a shorter time.
There are many sites that provide details on this agile technique. Here are a few references to get more background :
Comments invited. Are you comfortable working alongside someone? Would your management support this agile approach?
Ramblings on Release Management August 30, 2015Posted by Edwin Ritter in Project Management.
Tags: release management, release management process, software configuration management, software development, software development lifecycle
add a comment
From a recent project, one of the lessons I learned concerns release management and who drives that process. What I find most interesting is the developers’ view that once code is checked in, the deliverable is complete. I have worked organizations that use a formal software configuration management and release management process (SCM/RM). That role can be a fully staffed position working with development teams to get code changes tested and released.
Related to this topic is environment management and configuration, the related tools and workflow to keep the organization working on the right things and at the right time. Ultimately, the changes are provided for use by external customers to meet their business needs. Let’s not forget that customers keeps the business going.
The SCM/RM process can easily be used with change control to manage the code base consistently. When the SCM/RM is not the responsibility of any single person, I submit that the developer shepherd their respective code changes through the test and release cycles. What I find lacking is ownership from developers on following that through to getting code changes released.
While my expectations are influenced by past experience, I am aware that it is naive to expect other team members will have a level of ownership and commitment consistent with mine.
So the next time there is a change, I will use my greater understanding on what is needed to keep things moving and align my expectations. A lesson learned and one that I am willing to share with others.
Comments invited on the level of effort and ownership with release management. Who drives changes through to release? Is it automated in your shop? What tools and process do you use to manage the code base?
Robots to displace humans in certain jobs July 26, 2015Posted by Edwin Ritter in career, Trends.
Tags: carbon based life form, jobs, labor force, robot, robots
add a comment
Let’s get this clear right from the start – I am a human writing this article. That can change some day in the future, but for now, a carbon based life form is forming these thoughts and expressing them to you. I enjoy seeing the musings that predict how the labor force will change as robots are being used in more and more job roles. One thing I know for sure is that the rate of change is never as fast as the predictions say they will be.
I think the definition of what is, and is not, a robot is still a bit elastic. For me, a simple definition is a device using mechanical, electrical and software components that can perform a series of steps that result in a work product repeatedly with quality similar to, or, exceeds when the same work product is performed by a person. Regular readers know I have mentioned the topic before and I have been paying specific attention to the progress with robots driving cars. That is a change I welcome and hope to see in my lifetime. In the interim, there are jobs that robots are performing already and we will see other jobs that can, and will, be performed increasingly by robots.
I expect one area that robots can be a competitive advantage is in business recovery. Simply stated, using robots ensures the business is always available using redundancy and fail over/recovery tools performed by robots based on triggers set by humans. Relative to the definition used for robot, there are companies that can state they already are doing this. Going forward, I expect this capability will be common place in more and more industries.
At present, here is a NBC News article that lists these 9 jobs robots can do as examples:
- Lawyers and Paralegals
- Driver (Can’t wait!)
- Store Clerks
- Baby Sitters (way distant future)
- Sportswriters and reporters
Each of these is plausible where a human could eventually be displaced by a robot. From this list, robots are already working in some of these roles. For other jobs listed, many changes are needed before a robot is capable to do the work. Last, for others, there will be much resistance, consternation, hand wringing and posturing in opposition to robots working in those roles. Also, notice jobs that are absent from this list (teachers, doctors, programmers, managers).
While robots transition into these jobs as well as others, that implies that us carbon based life forms will be working in new jobs. That is a consistent theme from what I have read. The robots will enable us to do new work as we use the results of their labor for our jobs. Here is another article that begins to describe that effect.
The changes implied in the transition will range from the simple to the complex. In many cases, a one to one direct replacement from carbon life form to silicon based worker is possible. In other jobs, getting work to a point that the steps involved are repeatable (and, consistent) may drive ripple like changes to other jobs. The resulting changes required will happen with more and more frequency and in jobs that we do not anticipate at this time.
How will you prepare for this change? What impact will that have on your job? How can you use robots for your business?
Comments invited and the next update on this topic may, or may not be, written by a human.
Multitasking is a myth June 16, 2015Posted by Edwin Ritter in career, Project Management.
Tags: Cognitive neuroscientists, decision, multitask, multitasking, priority
add a comment
All employers want it and every employee attests they can do it. Cognitive neuroscientists will tell you that multitasking is not possible. A myth, popular misconception and a white lie employers and employees accept while knowing it is a fallacy. In fact, studies reveal that only 2% of people can effectively multitask.
I understand how multitasking is a desirable trait to have. But, the reality is very few have this ability. Studies also have proved that you are less effective doing multiple tasks versus being singly focused. So, let’s agree to ban multitask as a phrase from job descriptions and be realistic about how to get work done. Having the ability to work on many things in different phases is not multitasking. It is just that – working on many things concurrently. Being able to prioritize is a highly desirable skill to make effective decisions. Maybe that is the better term – prioritization.
Recently, I read about how the mind works and how we organize information. Turns out that we have a system for what grabs our attention. We process information using an attentional system and it has four parts.
1) Default mode – fluid and non-linear thinking (let the mind wander). This is the default mode when the brain is resting. Leads to the creative state. In this mode, thoughts are inward to desires, feelings, planning, daydreaming. While in this mode, we feel refreshed after a nap or vacation.
2) Central Executive mode – stay on task; focused. This is the other dominant mode for attention. Opposite of the default mode; they are yin-yang and exclusive. When one mode is active, the other is not. Writing reports, problem solving, painting are examples while in this mode.
3) Insula – is the ‘switch’ between the default and central executive. Enables shift from one mode to another. A neural switchboard. If the brain switches too often it can lead to dizziness with information overload as a result.
4) Attention Filter – What grabs our attention and causes a change in focus from what is in the sub-concious.
Our brains have a finite capacity to process information. We can keep about 4-6 things in mind at once. Keeping track of too many things requires switching and leads to fatigue. All that switching takes energy, can cause information overload and leads to mistakes or otherwise being unproductive.
Along with information overload, our attention filter has a blind spot. Things that we need to pay attention to; details that impact our decisions can be easily missed. A famous example of the blind spot and selection attention involves a group of people passing a basketball. Clink on the link and watch the selective attention video if you have not seen it before. I’ll wait. See what I mean?
This is formally known as Attentional Resource Theory. When we are focused on a specific thing, it uses most, if not all or our ability to process information. Cognitive studies prove the theory and explain why performance is hampered when multitasking.
We know the brain is a very complex instrument. We continue to learn how it works and these new learnings on how we manage information and make decisions will shape how work is organized, performed and how productive (see post on Capacity & spinning plates) any single person can be.
I admit to not being a multitasker. Not part of the 2% who can. But, I am good at setting and keeping priority to make decisions and I know my capacity.
What techniques do you use to manage your workload? Comments invited, as always.
Gate Review Ramblings May 29, 2015Posted by Edwin Ritter in Project Management.
Tags: gate review, milestone, project, project deliverables, project management office
add a comment
So, one of the projects you are involved with is under way and soon you need to provide an update to the gatekeepers. You know, those people who approved the project and now want to know what’s going on. Depending on the tools and process used, getting a formal project update together can be a formidable task. Projects can change daily so getting the most up to date on status, issues and path forward can be time consuming.
I have found that using a consistent format to provide project updates works best. The gatekeepers know that format and also when to expect updates. I have heard that many project managers don’t like gate reviews. I enjoy them and look forward to meeting with the decision makers who have a vested interest in the project. Getting them in the same room and having one conversation about the project is great. Summarizing the good, the bad and path forward is key.
Regular updates on projects as it progress through each phase is a good thing. Planing for the milestone reviews helps keep the team and the sponsors in sync on where the project is. As part of the gate preparation, I review the updates with my team prior to a gate review. That way, they are aware of what is being said and can revise/improve as needed. Also, getting them in sync with recommendation(s) is also key. Last, the team knows what is the path forward and where are we in the journey to deliver the project.
Some of the lessons learned I found from gate reviews include:
- Be honest – provide the facts, do not gloss over things. Provide the good, the bad and the ugly. Most managers know what is going on in the area of expertise anyway so confirming what they know is a good thing.
- Be clear – summarize progress, current status and recommend path forward. Use a stoplight chart or milestone summary to indicate what is done, what is left and what is next.
- Be candid – ask for help where you need it. By being proactive and committed to success, you are indicating what is needed to keep a project on schedule. Assistance can take many forms and can include resources, applications, training and funding.
Each organization executes the phase and gate process differently. Using a stop light chart is great to visually show the project health. It also provides a way to review the top issues and how to resolve them. Getting everyone on board with what, how and who is one of the best outcomes of a gate review. The best is a pass of course and moving on to the next phase.
At each gate review, there are basically three recommendations:
1) Pass – all deliverables are done for the current phase and the project is ready to move forward.
2) Fail – major issues are unresolved and need to addressed to move forward. Regroup when the issues are completed and ready to pass the gate.
3) Shut down the project. Not used as often as the first two recommendations. However, a viable and valuable recommendation when using the process correctly. This recommendation provides a way to show when a project will not succeed, does not have positive ROI and/or does not satisfy the requirements assigned to the project.
When there are multiple projects in a portfolio, using the stop light chart condenses the project health clearly and provides a great visual of how each project is progressing. Typically, the project management office collects and manages this information on all projects.
Use gate reviews to your advantage. Ask for help where you need it, stay on track and report progress at the next gate milestone.
A project is more than a schedule April 26, 2015Posted by Edwin Ritter in Project Management.
Tags: manage, project, project management, schedule
add a comment
There are many things involved to run a project. Documentation, people, time and money are always involved. As data sources, they are used to develop a project schedule. To manage the tools and processes, a project manager needs skills. Hard skills, soft skills, people skills and technical skills are a few.
As a PM, one of the simplest questions asked is “What’s the schedule say?” A good schedule provides the data on what’s done, what is being worked on and what’s left to do. The schedule easily answers the question “Where are we?” Variations of this include “Are we there yet?” or “What’s next*?” and “How much longer?”
*A favorite of mine, especially when asked by someone on the team. Shows commitment, dedication and confidence on their part. Always good to have those people on a project team.
At times, I have seen an over-reliance on the answer of what the schedule ‘says’ by a manager or customer. Heresy, I know. Don’t get me wrong. I am all for planning, scheduling and getting tasks assigned to dates. But a project is more than a schedule.
The schedule is one part of the project. It shows where you’ve been, where you are and where you are going. Other parts of the include budget, resource allocation and responsibility. Combine those with the assumptions, risks and choices made that then result in a project.
When someone asks “Well, what does the schedule say?”, it says to me that they don’t agree with what they heard. Expectations are not met and something must be wrong with the schedule. When, not if, a PM is then asked “What is wrong with the schedule?”, the answer(s) should be “Here’s what is wrong with the project that results in this schedule.”
There are ways to find out why a project is not aligned with the schedule. From a previous post, here are six signals to review.
What’s your take? Comments invited, as always.
The Level of Math in Risk Management March 28, 2015Posted by Edwin Ritter in Project Management.
Tags: risk, uncertainty, risk management, decision process, decision matrix, known unknown, unknown unknown, decision theory
add a comment
Managing risk and selecting the best mitigation choice can be hard. There are many factors that will influence what choice is selected. Using data to manage risks and assess choices is always good. Having a process to use that data to evaluate choices is better. Having good data to assess risks and a process to determine choices is the point of this post.
Some background first. Decision theory is a complicated subject and is used in many different fields in business and leisure (i.e. – games). There are 4 basic elements in decision theory: acts, events, outcomes, and payoffs. A formal definition is “the mathematical study of strategies for optimal decision-making between options involving different risks or expectations of gain or loss depending on the outcome.” An informal definition of decision theory could be “identifying the values, uncertainties and other issues relevant in a given decision, its rationality, and the resulting optimal decision.”
Got that? Good. Sorting out between what is known and unknown can assist in which risk mitigation choice is best. It is always preferable to be in the magic quadrant and deal with knowns rather than unknowns. Consider these groups in a matrix:
- Known Known – circumstances or outcomes that are known to be possible, it is known that they will be realized with some probability.
- Known Unknown – circumstances or outcomes that are known to be possible, but it is unknown whether or not they will be realized. This is known as a Risk.
- Unknown Known – circumstances or outcome a modeler intentionally refuse to acknowledge that he/she knows.
- Unknown Unknown – circumstances or outcomes that were not conceived of by an observer at a given point in time. This is known as an uncertainty.
In short, those things we know we don’t know are risks and those things we don’t know what we don’t know are uncertainties. In the magic quadrant, both are below the line.
Still with me? The uncertainties, the unknown unknowns, are the hardest pieces to deal with. With decision theory, assigning values of probabilities helps determine which choice is best. As an example, consider the following image. Getting the data to assign the options and organizing into a concise arrangement is where the math comes in.
Not all risks require this level of math and analysis to determine the best mitigation choice. The level of math should be appropriate to the complexity of the project and the potential risks involved. It is worth noting that the difference between an issue and a risk is :
– an issue is something that has occurred which impacts* the project.
– a risk is something that may or may not occur that can impact the project.
* impact can be positive or negative.
I prefer to stay above the line and deal with knowns and those risks that are relatively small on my projects. It makes for simple math and for projects where my preferences matter, I find those are the best projects to manage.
Glad I did not lose you and you got this far. How do you manage risks? What is the level of math required for risks? Simple? Complex? Hybrid? Comments invited.
Cloud Life in 2015 February 27, 2015Posted by Edwin Ritter in Cloud Computing.
Tags: cloud, cloud computing
add a comment
Are we there, yet? Seems everyone is talking about cloud services these days but not everyone has migrated. Once you and your team have configured the repositories, gotten used to the tools and established new or revised processes, life is good. The migration can vary of course from easy to arduous. One thing that seems to get glossed over is moving things from here to there. Things like project assets (images, videos, content – you know, stuff), documentation, spreadsheets. I know, I know – it’s very easy. Drag and drop. It is easy, to a point.
While there is a lot of talk about cloud services, it seems to me we are in the early stages of life in the clouds. We are still using desktop based tools, not cloud based widgets. I imagine a day when setting up repositories will be done for groups of files and directories using objects. Content management via metadata and aligned with a specific taxonomy. What’s that? It exists already? Yes, it does in certain places but it is not ubiquitous and not homogenous (yet). Too often, we are dealing with unique files, not a larger data set.
In the interim, it’s about the journey not the destination and keeping the business running while you migrate. Tools change all the time and there will be a day when migrating/updating/changing repositories will be done at a higher level than it is today.
And, hey, you – get off of my cloud.
Virtual Work January 30, 2015Posted by Edwin Ritter in career, Cloud Computing.
Tags: life-work balance, remote work, virtual office, virtual work
add a comment
While in the office, how many times have you heard someone ask the old saw ‘Are you Working hard or hardly working?’ Funny when used at the right moment and a proven gambit to spark friendly banter among co-workers. In the digital age that is reflective of current work practices, a variation to the phrase could be ‘Are you working virtual or virtually working?’
The difference is more subtle than you might think. Working virtual can mean working remotely. That is, you may not be in the office for a short time but will be back physically. The expectation of management is that while remotely working (wherever that may be), you will be working on the same tasks as when in the office. Virtual work is conceptually similar but different in that you are never physically in an office with co-workers. No office cubicle, no ad hoc hallway or water cooler conversations, no in person meetings or face time.
There are definite advantages to virtual jobs. Top of mind advantages include:
- life-work balance,
- minimal commute time and
- flexible work hours.
Having a virtual job is not for everyone and certainly not possible with all jobs. It does take different habits with virtual work. Making the transition to working in a virtual office also requires a change in mind set. Being comfortable with having lots of alone time is part of the transition. The interactions with co-workers is reduced and takes a bit more effort (and, time) to pose a question, have ad hoc conversations via chat or email.
In response to the question, I am virtually working and enjoy what I am doing.
2014 Ruminations in review December 29, 2014Posted by Edwin Ritter in Trends.
Tags: annual report, Ruminations
add a comment
The WordPress.com stats helper monkeys prepared a 2014 annual report for Ritter’s Ruminations and Ramblings blog. Here is the year in review.
Here’s an excerpt:
A San Francisco cable car holds 60 people. This blog was viewed about 2,600 times in 2014. If it were a cable car, it would take about 43 trips to carry that many people.