Jason Ziegler- Professional challenge- Interviews

For my professional challenge i interviewed Bonnie Barker from SAP, and Brian Gould from Safeway:

Bonnie Barker – SAP software Developer

Bonnie Barker is a software developer for SAP Software & Solutions, specifically developing Information systems for fashion retailers including demand forecasting based on previous years data.

On an average project, she uses a lean strategy. They used to follow a waterfall strategy but changed to lean in order to be more flexible and responsive to changes in project requirements and scope. In a waterfall system they would have to throw everything out and start over if something was changed, which is not the case with a lean strategy. They usually break it up into 1 month cycles. For software development they almost always use AGILE strategies, and follow a “Tester, then development” process. She uses SCRUM virtually every day, and on ever project she is working on.

Usually, when working on a project, you will be on a team, but will have individual pieces of the project as their own responsibility, and will only meet to put them together. When you do peer programming, you can only ever do it for a few hours because it hurts morale and is exhausting. Peer programming is usually only done to solve a problem, rather than work normally on a project together. Mrs. Barker is considered an expert at her company, so she usually peer programs with other people in order to mentor them, or upscale them. Meaning that she is training them to be better at something, rather than just working together as equals on a project; she usually does this to train someone to cover for a planned vacation or sick leave.

Most communication with her team is done face to face, but she starts her day with emails about whatever problems had popped up overnight. Conference calls are reserved for long distance teamwork- such as a project involving the team based in Switzerland recently, where they were skyping every day for a few weeks. But usually, the best way to communicate with your team is to walk over and talk about whatever you need to talk about.

When asked about her daily routine, she said that probably half of it is putting out fires, with the other half mixed between working on projects, and other tasks. Sometimes it is all problems, because she has become an expert with their environment and system- newer people working in IT invariably spend more time on their tasks, but as their experience grows, they end up becoming fire fighters a lot more because people will go to them for their expertise or opinion.

According to Mrs. Barker the most common failure in project management is that people always set their deadline first, and then try to shove too much into their schedule up to the deadline. Instead, they should set the deadline, and find the absolute bare minimum that they can deliver as a shippable product by that time and then if they accomplish that, reevaluate for additional features. This is much better than wasting time on features you never finish and miss the deadline, burnout, or both. Managing scope is the biggest failure in project management, with communication failures (Either from poor, or lacking communication) being a close second.

In contrast, the most successful project managers are the ones who pay attention to details. A good project manager is able to motivate people, and get work done, even when they have no authority over them. Simply telling someone to do something isn’t enough. Too many project managers are certified Project Management professionals, but they don’t know what they are doing- even if they understand the terminology. It is all about the details and being energized enough to go that extra mile for your team’s success. Additionally, free food is always a valid and reliable strategy for mission success.

The most important skill for someone working in IT according to Mrs. Barker is communication. The better you are at communication, the better off you are no matter where you are working. Additionally, no matter what you do, knowing an object oriented language is required. You don’t have to know all of them- after the first few languages, learning a new one is really just all about learning the syntax, because you end up framing questions and thoughts to solve problems using the language. It is more important to understand how to organize your program.

As for advice for someone going into the IT/IS field, the best advice she could offer was to “stay on top of your game,” meaning to keep learning new skills, and updating old ones. Essentially, don’t get complacent in a position and become a dinosaur. Stay flexible and be able to adapt to new jobs- you won’t be in the same job you started at, 20 years from now. Mrs. Barker is a programmer by trade, but she couldn’t apply for an open, and very good, project management positions when she lost her job because she wasn’t certified. So when she found another job she studied for the certification, so that if she ever needed another job she could get it.

The most important thing according to her is to do something you love. Don’t do something you hate for longer than you have to. Pay the bills, but find a way to do it by doing something you love doing because you will be doing it too much, for too long, for it to be something you don’t love doing.

____________________________________________________________________________

Brian Gould- Safeway, Business Intelligence Dept.

Brian Gould is a Senior Tester for Safeway’s Business intelligence department, and the former director of Quality assurance at Apollo Group and the University of Phoenix. Currently, he is working on an in house web based inventory storage accounting system, which is used to process inventory for Safeway, in order to keep products on the shelf and anticipate fluctuations in demand. While working for the Apollo Group, he designed, developed, and managed an SIC for online classrooms, much like the Blackboard system ASU uses currently.

Mr. Gould virtually always uses agile development strategies on his projects. The biggest reason for doing this is that it lets you fix mistakes before they become a really big problem, which is what happens when you use a waterfall system, and wait until the end to confirm that you are doing what you are supposed to be doing, in the way the product owner wants it. When I asked him about Scrum he laughed and said he lives in scrum, and every product uses it. He also talked about his daily meeting, which he called a “daily standup” because it is essentially a daily meeting where everyone stands around in a circle. They do it standing because it is supposed to be short and to the point. The scrum master is in charge and organizes the meeting, which is usually very early in the day, as a sort of check in. This is very similar to what we have done at Target, with our daily huddles. Mostly, they go around the circle, and say what they did yesterday, what they plan to do today, and anything that might be an obstacle that they might need help on. If there is anything else that needs to be said or addressed in more detail, they schedule a secondary meeting specifically to address that problem.

Mr. Gould’s daily schedule is basically to check his email for any outstanding problems, and to address those problems. Then, when he has solved those problems, he begins to work on his main project, with additional firefighting throughout the day. The daily standup meeting occurs sometimes during that problem solving, or possibly between finishing dealing with those problems and starting in on his regular project, or sometimes afterwards- depending on the status of the team.

Every project is as part of a team. Everyone works on their sections separately but, as a team on a whole project, so that everyone is there to help each other when they need it. Usually a team consists of three developers, two testers, a scrum master, and the product owner. Usually, one of the best ways to communicate as a team is to sit close together, and have face to face communication. One of the most common is to stand up at their cubicle and catch the other person’s eye, or talk to them if they are close enough. He called this “prairie dogging.” Either that, or go walk over to them. The second most common way to communicate is via email. For some reason everyone hates using the phone to talk, but texting is decently common.

When working on a project, the most important thing is to prioritize from the technical tree. Focus on what you can accomplish, and on what is most important and do that. Identify all of the secondary features, and set them aside for if there is extra time. Project management is basically “herding cats” (That is a technical term) and the last thing you need is to have herded them into doing something that isn’t necessary, and something vital doesn’t get done. The hardest part of a project is identifying the requirements for a project. There is often a gap between what is said, and what is actually needed. Your job is to close those gaps, and make sure the end product fits what the product own actually wants. One of the biggest trappings you will run into is that customers will tell you their solution to a problem, rather than just the problem. Don’t ever agree to their solution until you understand the problem and are sure it is the right solution- product owners always think they know more than they actually do about the process.

The most important skill for working in IT is being analytical. You have to be able to take any problem and break it apart into all of its pieces, and identify what is really wrong. Listening, and knowing the right question to ask will make or break a project manager.

Professional Challenge: Book Review of Managing Humans

Managing Humans by Michael Lopp

This is more a collection of Michael Lopp’s blogs than it is a book. It is not sequentially or systematically in order, which kept it interesting for me. In the first few introductory chapters, Michael describes the relationship between a person and his or her manager. It also provides a framework to identify who wants what from a meeting. It involves knowing you agenda before going to the meeting and facilitate the issue to move in the correct direction, and then leave the meeting. According to Lopp, our job as a manager is to give relevant information and constructive feedback to the employees. If we don’t, then they might start engaging in gossiping and other unproductive activities.  Although the impression is that managers typically lead by “talking”, the author concludes that managers should start listening to their workers more. Guiding through filling the air with words is ineffective and irrelevant if managers have not gathered and/or processed data.

The author introduces the management lingo, “managementese”, which is managerial slang that helps people from different parts of the organization to understand each other. However, Lopp warns us to not use managementese not because they might not understand what is being said, but because they might not trust the informality.

When discussing the question of whether the manager should code or not, Lopp very aptly advices to “Stop coding, and start programming.” This is because managers should be skilled in drawing extensive architectural plans that adequately describes the product. Another chapter uses the story of a problematic programmer named Fez as an example to show how to prepare for an annual review. It also exemplifies the ways of evaluating your employees.

I enjoyed reading the chapter on the do’s and don’ts of leaving a company. Although some of them were relatively obvious, I found other surprising. For example – “Don’t volunteer to do work after you leave” is interesting because I tend to be the kind of person who would like to help out if requested. Lopp also gives some very specific ideas on how to work for launching a new product. “Two meetings a week: one for brainstorming and another for prototype review.” 

The book also describes a psychological phenomenon of background processing and decision making that I found very intriguing. He also defined Malcolm Events as “Seemingly insignificant events that are intent on screwing you in an unlikely way.” According to the author, it is hard to recognize the effects of these events because of their insignificance.

Interestingly, the author explains that managers have 90 days to complete an interview of the person on a new job. The author suggests to involve a “technical bully”, “culture compatibility detector” and “vision detector” while having the interview. Each person should talk to the candidate individually. Afterwards, the manager should ask for feedback from all three.

Using the author’s descriptions of the three different types of managers according to the direction of their attention, I deduced that I am an inward and holistic manager. Inwards look towards their team, holistic look across the organization, and outwards look outside of the organization.

Despite being an interesting read, I have a complaint from Managing Humans. There were several grammatical mistakes and typos in the first few chapters of the book. Other than that, the book was definitely worthwhile reading and gave me some inspirational insight to management processes.

Professional Challenge: Book Review of The Phoenix Project

The Phoenix Project by Gene Kim

             The Phoenix Project is a book about a large public company, Parts Unlimited, which sells car parts. Parts Unlimited is facing several technical and managerial problems that are making it difficult for the firm to cohesively work in teams to make projects succeed and become better than their competitors. The culture of blame games is common in the organization and the employees are over dependent on individual managers to achieve project goals.

             The first ten chapters has real-life examples of the many opportunities that the company missed only because there was a significant lack of communication among the workers. It highlights the problems organizations face because of their IT and technology’s incapability of supporting their company’s needs. 

Some of the examples and scenarios Kim presents in his book are so real and relevant and that it is easily comprehendible. The book describes how Bill Palmer, the VP of IT operations starts learning about and implementing DevOps and other efficient IT operations. Gradually, he realizes that IT impacts all departments of the company and he also learns the procedures of operations, product development, marketing, and sales.

               According to the book, DevOps is a software development method that emphasizes on having strong and consistent communication, collaboration and integration between developers and IT professionals.”  According to this book, this approach uses the agile method and forces the production of more frequent releases of code which, ultimately, increases the ROI on the code. From the IT’s perspective, DevOps requires that the test and production environments are standardized. It also asks that packaging codes and troubleshooting techniques are also automated. Many professionals agree that, in these days, automation may be vital to improve efficiency in IT departments in all sizes of companies. Automation coupled with having effective management policies, can make any IT department function smoothly.

                Although this book is more relatable to companies that are heavily dependent on highly complicated technology, it is easy applicable to any company that has an IT department in it.  The certainty of experiencing unexpected situations and unplanned circumstances are so high that it is impossible to not face challenges as an individual or as a company. This book helps the reader think beyond the box and perceive business operations from a larger perspective. It shows how to promote an organizational culture of continuously learning and providing feedback is encouraged.

                 The book concludes with a reminder that DevOps doesn’t guarantee hundred percent success in process management, or that project deliverables and objectives will be met flawlessly. However, the book, after critical research and analysis, confirms that with sincere teamwork and constructive collaboration, everyone are motivated to perform their best at resolving problems. This approach encourages employees to adopt an agile approach and control the organizational environment without reducing to accusations and blames.

                  In summary, Bill Palmer used the tool DevOps to make his employees break down functional barriers work in order to collectively achieve the set business goals. By gradually changing their organizational culture and the way his team looks at their job’s role and responsibilities, Bill was able to increase Parts Unlimited’s productivity throughout the company. 

Professional Challenge- Attend IT/IS Professional Meeting #3

The third and final professional meeting I went to was with the Phoenix Scrum Users Group on April 10th.  This week's presenter was Ken Ruben, author of Amazon's best-selling book "Essential Scrum: A Practical Guide to the Most Popular Agile Process."  Ken is also a Certified Scrum Trainer and the Managing Principal at Innolution.  

Ruben's discussion topic was about how to scale your work groups to support large products.  Many groups are organized around the following: 

• Product Platform
• Component
• Product Feature
• Job functionality
• Location

One comment that was very interesting was "That which is a feature to a component team is a task to a feature team."

Ruben believes that you should scale your team based on economic factors and tradeoffs.  The work of your projects should flow through the collection of teams in an economically sensible way so that you will have maximum lifecycle profits.  

He recommends that teams should identify where the technical waste exists.  However, recognizing waste in technical development is difficult because it is neither physically or financially visible.  So rather than focus on what is invisible, focus on what you can see.  Ruben compared this to a relay race.  You shouldn't focus on the runners and making sure that each one of them is staying busy the whole race, you should watch the baton (i.e. the product).  All you have to do is make sure the baton is taken careen of and you will finish the race.  High personnel utilization most of the time doesn't equate to high productivity.  You should worry less about what your utilization is because it will find its natural rhythm.  

This speaker was very engaging and I would love to get his best-selling book to understand Scrum further.  

Professional Challenge- Attend IT/IS Professional Meeting #2

The second professional meeting I attended was with Phoenix Scrum Users group again.  It was held at Infusionsoft in Chandler on March 20th.  The meeting was a question and answer session with three product owners from three different sized companies.  The panel consisted of:

• Jeff Schinella with Axosoft
• SarahJane Isom with Infusionsoft 
• Josey Borman with Pearson

One question asked was why the product owners liked their job and where they worked.  Their responses included:

• Schinella-  Axosoft has a relaxed atmosphere that allows employees to express their ideas freely
• Isom- She likes to change peoples' lives and Infusionsoft gives her that opportunity with their 60,000+ users.  She loves to learn about each one of her clients and what their companies are all about, especially the small, start-up companies. 
• Borman- Her job has given her the opportunity to show her strengths.  She also enjoys working with her peers.  One of the negatives about her job is gaining trust on risky decisions.  

The second question was in reference to the acronym AKA (Authority Knowledge Availability) and which word held the most importance in their job.

• Borman- Having an authoritative presence and being available to your team was most important.  Knowledge is important but that is something that can be learned overtime. 
• Isom- Availability is  most important.  When a team can't meet and collaborate freely and easily, they are more productive.  It's better to have your team all together so that when their is a problem, everyone can gather around to fix the problem rather than having to schedule a meeting and wait. 
• Axosoft- Authority is most important.  Availability is very important but in his small company, it isn't a challenge.  Communication and collaboration is easy.  However, too much communication and conversations can become a problem. 

It was very interesting to hear the thoughts and opinions from individuals from three extremely different companies.  Each person has distinct challenges that they have to deal with but many of them they also share.  It was encouraging to see three people that truly enjoy their jobs and the problems that come with them. 

Interview with JT Marino

Interview with John Thomas Marino

I was able to conduct an interview with John Marino, who is the lead developer and also the cofounder of Tuft & Needle, an online mattress company. He started off his career by working as a software engineer for Hashrocket and then moving to Palo Alto to work for a startup called Mulu. After about a year at Mulu, he decided to start his own company, so he, along with Daehee Park, left Mulu and started a mattress company called Tuft & Needle (https://www.tuftandneedle.com/). The goal of Tuft & Needle is to bring more transparency into the mattress industry by getting rid of the price gimmicks offered by most mattress companies. In my interview with him, I focused the scope of the questions about Scrum, as he has had experience working in that type of team during his years at Hashrocket and Mulu.

Q: From your experience, what are some of the benefits of using scrum?

A: What’s great about scrum is the tight feedback loop that it offers. You are always aware of what’s happening in the team and in the project. The frequent update meetings holds people responsible and accountable. It encourages people to work harder because they want to show you something the next day. On the other hand, if you are slacking and if you don't have any updates, it could get embarrassing. In my opinion, Scrum is good when working on complex problems or projects as it allows you to break the project down into smaller problems. For programmers, this type of work flow really helps because you never get interrupted unless you’re doing your scrum update meetings or reviews. During that time, you can update the team about any blockers (things you need help on from another team member). Overall, scrum is all about certain rules and rituals and most scrum teams follow them rigorously.

Q: What are some of the disadvantages you saw from using scrum?

A: The way some teams practice scrum, there are just too many rules. The update meetings don’t have to be done every day. It gets to a point where it’s almost micro-managing. Although there’s not really a “manager”, you feel the pressure that you have to give some type of update every day. If you’re critiquing every day, it puts you in a box that you don’t need to be in.  

Q: From the experiences you had with scrum, what are some successes you had with project management processes?

A: With the things I learned from scrum, I definitely utilized the things I thought were effective but then changed a bit of things to make it right for our team here at Tuft & Needle. The biggest thing I wanted changed was the daily updates. Rather than pressuring employees to provide updates on a daily basis, I changed it to a weekly thing. If you want to take a day off, take the day off. I think it’s equally as bad if somebody delivers too much. This means that people will get burnt out, and what I’m trying to build is a sustainable team and that’s just not sustainable. The key strategy for me is to have each team member focus on one thing every week. If we have someone focusing on one thing each week for 52 weeks, imagine what he/she could accomplish in a year! In order to balance the daily workflow, I also encourage my team members to have a daily checklist. By having a daily checklist, you can see what other team members are blocked on. Ultimately, this allows there to be less meetings, which allows everyone to be more focused.

Q: What failures or disappointments have you experienced regarding aspects of your project management process?

A: I believe people work best with freedom and without any restriction or constraint. So when I first started off, I allowed people to just take charge and do something well. But, I late realized that too much freedom can backfire, mainly because they don’t do the work you originally wanted them to. Their work isn’t what you expect, and that was primarily my fault. So what I learned from that experience was that I needed to create criteria. Essentially, I have to create and define the box for someone to work in, and when you do it right, that can be a very powerful box.

The Lean Startup Review

With so many startups popping up left and right, management styles are also shifting as well. With much smaller companies in such a fast paced environment, it is crucial for startups to work and innovate quickly in order to be ahead of the game. In the book The Lean Startup, Eric Ries tries to tackle this challenge of managing startups through a lean management technique. Before he gets started, Eric defines the goal of innovation (or the goal of all startup companies) is “to learn that which is currently unknown.” With this in mind, entrepreneurs shouldn’t be thinking, “can something like this be built?” but rather “should it be built?”

Focusing more on lean management, Eric says a team should practice the Build-Measure-Learn Feedback loop.

As shown in the figure above, the loop is a cycle where a team continues to learn from what it builds through measuring its output with the proper metrics. The key to this cycle is to go through the loop as fast as possible. Thus, the scope of each of their “build” phase should be small. After each small release, a team should constantly measure itself, learn from the metrics, and then use what they learned to focus on what to build next. In Eric’s words, he states that “the faster they can learn, theoretically, the faster they can create a sustainable business.”

In order to properly, yet quickly, go through the loop, Eric focuses on three points. First, the team should employ continuous deployment, which means that the team should deploy small batches in order to get quicker feedback. Also, the metrics they use should be actionable. The last point Eric touches on is that a team should start each loop with a falsifiable hypothesis. This allows a team to “create predictions for each change that can be proved correct or incorrect.”

These hypotheses that Eric mentions should eventually grow into two different types of hypothesis. One, the value hypothesis, asks the question, “Does the product or service really deliver value?” In order to help the business become sustainable, the growth hypothesis should also be asked: “How do new customers discover a product or service?”

Ultimately, Eric encourages this type of loop because it allows a team to have “learning milestones.” These milestones allow entrepreneurs to make decisions based on facts discovered through the loops.

However, there will obviously be certain loops where things don’t go as planned or the metrics show a negative result. In these cases, a startup should needs to consider a “pivot”. Similar to basketball, a pivot is “a specific kind of change designed to test a new fundamental hypothesis about the business, product, and growth.” A team can look into various different pivots, but Eric mentions a few in his book as Customer Segment Pivot, Customer Need Pivot, Value Capture Pivot, and Technology Pivot.

Overall, a team’s goal should be to strive for sustainable growth. In the book, Eric defines “sustainable” as “new customers coming from the actions of past customers.” This can happen by word of mouth, as a side effect of product usage (other users are invited by using the product as designed), or repeated purchase.

Although the book covers a lot more great internal management techniques and even how to measure engines of growth, the points I mentioned seemed most relevant to me as I continue to grow my interest in startups. Even in a corporation, these lean management techniques seem like a more effective way to run teams and projects. I hope to utilize these methods as I start my career after college.