Posted by Mike on April 8, 2010
Another insight to project I have gained from being both the project manager and a developer on the team is the disctinction between an implementation focus and a production support focus. As a project manager, your whole focus is on getting the project implemented. It’s a temporary endevour. A developer needs the implementation focus, but the developer also needs a production support focus.
Once a project goes live, it is often the developer who supports that system in production. The project manager has moved on to the next project, but the developer must support the application in the production environment. This involves follow-up and responding to issues as they arise. I confess that I have become comfortable with the implementation focus. I am finding that I have to remember to focus on production support, now that I am also contributing to the project in the developer role.
Posted by Mike on April 5, 2010
I have been learning the hard way what it means to have multiple roles in your job. I am working to get back into software development while continuing to be a project manager. I have found that software project management is greatly aided when the project manager has some development responsibilities. Last Friday, I was caught off-guard by a problem with my role on a particular project.
My role, as I understood it, on the project that “got me” was as the project manager only. Because of this, I was reading the requirements through my project manager eyes. My developers were reading the requirements through their platform-specific eyes. The result? We completely overlooked an area of development that was sprinkled throughout the requirements.
It happened to be a platform on which I am doing development on for other projects, so I can easily see how it was missed. The assumption was that I would take care of that piece, only I didn’t make the same assumption. The problem showed up in a reported defect, so now I am scrambling to catch up. I must be certain to analyze the requirements more carefully so that as the project manager, I make sure that all the developer skills we need are on the team, whether the developer is me or someone else.
You might think that this problem was obvious and could have been avoided. I can tell you that it wasn’t obvious to all who were involved because it was missed in two sprint planning sessions. Yes, it wasn’t obvious, but I should have caught it.
Posted by Mike on July 9, 2009
I googled the title of this blog post, as I am working through a difficult transition. I have been a full-time project manager (PM), but I am switching to 50% PM and 50% developer. I want to be the best developer I can be in that 50%.
Here is my story. I went into management for a better salary. Back when I did that, I had reached the top of the career path for developers – Systems Analyst. Several years into my time as an IT Manager, I was tapped to lead the Project Office. I oficially became a project manager and earned my Project Manager Professional (PMP) certification.
The more I worked with software development teams, the more I missed doing software development. As a PM, I also saw problems with software development that I figured would be hard to improve unless I got involved in the work. A hands-on approach would show me what was going on and build credibility for potential solutions.
My problem? Besides the tinkering I do in my spare time, most of my programming skills are rusty, out-dated, and underdeveloped. That being said, I have always been able to learn new things. With budgets tight, it is up to me to get started and prove my value. This is where the web really comes handy. There are so many good, free resources available for learning!
Here are a few that I am using:
Here are a few articles worth reading:
Finally, a couple book lists:
Here is a quote from the “Rock Star” article referenced above that sums it up nicely.
I’ve lost track of how many times this simple fact has been proven to me. The qualities of a great engineer carry over to any platform, and a great engineer will pick up a new platform quickly — mostly because they love learning new things. If you’re starting out in software development, concentrate on being a great engineer. That’s far more valuable than an engineer that knows a platform.
I have seen this too. If you look at the articles and book lists I’ve noted above, you will see that very little is said about specific languages. The languages are just the tools. They are important and you need to know them. However, it’s not the knowledge of languages that make a developer valuable. It’s the higher skills – learning, networking, understanding, and problem solving.
Posted by Mike on June 25, 2009
We were having our scrum yesterday and the discussion turned to three, low-hour, tasks that one particular developer has left to complete. He also has another larger task remaining to complete. His choice was to postpone the small tasks in order to complete the larger task. It will only take a maximum of four hours to complete the small tasks.
The BA’s on our team came to me later and spoke to me why these small tasks were important. (They weren’t sure they could speak to the impact during the scrum.) The accuracy of a key calculation, which is being tested right now in another system, was at stake. I requested that the developer put aside the larger task and complete the small tasks today.
As scrum master, I was acting to remove an obsticle that a different team was encountering. I also wonder what could have happened differently so that I wouldn’t have had to intervene. Could it be that with just a little extra push, the developer could have completed this task earlier so it wouldn’t have become an issue? Could it be that the importance of this task been discovered earlier in our sprint?
What do you think?
Posted by Mike on May 28, 2009
If you are an industry underdog, then:
- “If you’re outmatched by the competition, isn’t it silly not to take a chance?”
If you are the niche leader, then:
- “Right now, great teams (such as the Colts and Patriots) use the no-huddle selectively, as a way to maximize their dominance.”
Hmmm… Is agile software development, kinda like the no-huddle offense?
- “Why not put together a lighter, better-conditioned offensive line and a radically simplified playbook and see what happens?”
Perhaps smaller teams in coordinated efforts will improve speed to market?
- “The strategy that’s right for heavyweights has nothing to do with how welterweights should fight.”
Something to aspire to:
- “Generally, he’s doing so much more with so much less.”
Posted by Mike on February 20, 2009
I have been teaching myself Java. Starting out, I am reading Java For Dummies
. I also needed some kind of practice exercises that give me immediate feedback on how I am doing. Fortunately, through The Java Tutorials’ Weblog I found a great site called JavaBat.
JavaBat is a free site created by by Nick Parlante who is computer science lecturer at Stanford. It contains numerous coding problems and gives immediate feedback if your code solves the problem correctly. (The site can also be a good tutorial on unit test case development. Just study how the test cases are structured.) Helpful links to tutorial pages, as well as sample code, help you learn.
The site focuses on improving your method coding skills. Each area has a large number of problems to solve, ensuring that you can get plenty of practice. It also has the facility to enable a teacher to monitor the progress of his or her students.
I would bet that both new and experienced developers will find something on JavaBat to help strengthen their coding skills. It could also be used as a tool in evaluating potential developers you want to add to your team. Finally, I also like the the minimalistic design of JavaBat.
Posted by Mike on February 12, 2009
I just read a great article by Paul Graham called Holding a Program in One’s Head. In it, Graham, explores the value of programmers having large blocks of uninterrupted time to code. This seems like a simple way to improve the quality of code and the productivity of your developers.
He lists eight points that help programmers and makes the following observations:
- It’s striking how often programmers manage to hit all eight points by accident.
- Even more striking are the number of officially sanctioned projects that manage to do all eight things wrong.
It looks like there is plenty of room for managers (and programmers) to improve!
Posted by Mike on January 31, 2009
Take a 2 million dollar project.
Industry data shows that outsourcing saves 20%.
Outsource the project above and it costs you $1.6 million.
Introduce Scrum locally and you can realize a 240% improvement.
Local Scrum for the above project only costs $0.83 million.
Source - Jeff Sutherland - 2006
Posted by Mike on January 30, 2009
I have been doing some research on agile software development methodologies, specifically Scrum, and found the following videos.
Posted by Mike on January 2, 2009
In the book,
The Toyota Way
, it is stated (p. 87) that “Most business processes are 90% waste and 10% value-added work.”
“Traditional business processes, in contrast, have the capacity to hide vast inefficiencies without anyone noticing – people just assume that a typical process takes days or weeks to complete. They don’t realize that a lean process might accomplish the same thing in a matter of hours or even minutes. – The Toyota Way, p. 88
It is also stated that the heart of the Toyota Production System (TPS) is eliminating waste (p. 27).
“The first question in TPS is always “What does the customer want from the process?” (Both the internal customer at the next steps in the production line and the final, external customer.) This defines value. Through the customer’s eyes, you can observe a process and separate the value-added steps from the non-value-added steps. You can also apply this to any process – manufacturing, information, or service. – The Toyota Way, p. 27
Toyota has identified seven types of waste in business process. There is also an additional eighth type of waste, which I have included in the list below. I have adapted these to the office environment.
-
Overproduction – Producing items for which there are no customer needs.
-
Waiting – Workers “standing around” waiting for the next processing step.
-
Conveyance – Moving work between different processes or storing work.
-
Over processing or incorrect processing – Taking unneeded steps to process the work or inefficient processing which produces defects. This could also be caused by producing higher-quality products than needed.
-
Excess Inventory – This is harder to identify in the office environment, but think about work stacking up in one function area. A constraint or inefficiency causes the work to “get stuck” at this bottleneck. There may be some functions that should be outsourced to eliminate this “inventory” from your business processes.
-
Unnecessary Motion – Any wasted motion that is performed during the course of work. Walking is an example of this. So are many meetings.
-
Defects – This refers to production defects that require rework, inspection, special handling time, extra cost, or lost revenue.
-
Unused Creativity – This is not in the core seven types of waste, but in the world of knowledge workers is a real form of waste. This happens when you do not engage or listen to your workers. It also happens when no time is set aside to think. The cost can be high in terms of missed opportunities to save time, capture ideas, and improve skills.
As you look to improve the efficiency of your business process, examine everything in light of the eight wastes listed above. Be brutally honest in your evaluation and then take positive action. This will help you identify and eliminate the real pain points that are holding your business back.