Ian Bush, Agile and Business Process Consultant

Virtualization

2010-09-09T17:32:00.003-04:00

So, I just finished some prolific reading on server virtualization to support an infrastructure plan that I am crafting. A few key takeaways that I thought were interesting:

1. 2010 and 2011 figure to be prolific years for virtualization with the number of virtual servers being installed equal to the number for years 2001-2009 combined.
2. According to the Gartner magic quadrant analysis, VMWare is still the 800 LB gorilla but Microsoft is coming on strong.
3. Further, the hype cycle (http://en.wikipedia.org/wiki/Hype_cycle) for virtualization is still greatly weighted in favor of the "peak of inflated expectations", which means that IT professionals need to be sensitive to how they plan to execute on the business needs or they risk purchasing products that are not "fully baked".

The final point that I found interesting was one that I thought really goes to the core of any type of technology purchase. In short, the decision to purchase and implement a virtual server environment is a strategic one.

What this means is that one should not rely on "saving money" through less data center space, etc as the primary driver for why you make a purchase because this decision is more tactical. If you are to make a correct decision you should focus on how you can make the business better through quicker availability of servers for business needs and other intangible business benefits.

While I am no expert on virtualization after reading the Gartner research, the articles really opened my eyes regarding how I might approach a virtual server decision. I strongly suggest that you take a look at the Gartner articles: "Magic Quadrant for X86 Server Virtualization Infrastructure", "Q&A: Six Misconceptions About Server Virtualization", and "Hype Cycle for Virtualization, 2010, if you are considering a virtualization purchase in the future.

Evaluating PM software solutions

2010-06-21T09:56:00.003-04:00

Recently, I have been evaluating a large number of software solutions for Agile project management including reviewing just about every company in the Gartner PM magic quadrant. What I have come to realize, is that with each piece of software it is what you make of it. Project management is the same way.

When I took the PMP exam, I put together a study guide that broke down the five aspects of a project plan (Initiating, Planning, Executing, Monitoring and Controlling, Closing) and its subsections, and studied until I had committed them to memory. With things like communication plans and stakeholder registries, I was armed to the teeth for the exam, but I realized that to most people those things are really extraneous, and in the Agile world, they make teams believe that the PM wants to execute a project with the waterfall method. A year later, I have a hybrid approach to the concept of a project and I use what works, not what I "am supposed to do" as a PMP.

I know that there is nothing in this post that is particularly "earth shattering" to read, but it is important to not lose sight of what is important in the real world. As my marketing teacher once said, the first strategic goal for a business is to stay in business. Our projects must execute efficiently for our business to keep operating and no one solution or practice will make sure that happens. We must adapt if we are to be successful.

What can brown do for you?

2010-06-14T09:31:00.000-04:00

Back in my younger years, I worked for UPS in their computer group and learned a lot about how their operation uses practices that keep the company moving in a positive direction. As an example, every six months, I was asked to count the number of steps that I took while walking around their warehouse facility so that the company could figure out whether I was working in the most efficient manner while doing my job. While some people would argue that I could just game the system and "fudge my numbers", the reality was that it was in my best interest to accurately report the information, so that management could find inefficiencies in the structure that made it harder for me to go from point a to point b. I thought this was a pretty cool thing at the time, but I have since learned that a lot of companies did this back in the early 90's, and UPS was probably just copying the other companies practices.

In a more unique way, one thing that UPS did then, and still does to this day, is wash each "package car" as they return to the facility as part of a nightly routine. While some people might consider this a waste of natural resources, it is actually part of their process to ensure that customers have a positive perception of the company. In an metro area like DC, their "total customer perception" is a pretty big deal with the large number of package cars delivering all over the area. Everyone has seen the "WASH ME" written in dirt on the back of a car or truck and UPS wants to be sure that the negative impression associated with those types of delivery vehicles is never associated with their business.

I think one could project this to their personal and professional image in the real world. As a professional looking to move up in their career path, one should endeavor to have a positive image with nice professional dress. Too often, I have seen someone in the corporate world with a t-shirt with some catchy phrase that while cute in the casual world, doesn't really belong in the corporate world. And in regards to the project management world, one should be prepared for any and all meetings.

In short, if you know your customer's conditions of satisfaction and what their functional/non-functional requirements are, and are prepared for their questions, you will never be that dirty delivery vehicle on the career highway of life.

MS Project as a tool for iterative development

2010-05-20T13:46:00.003-04:00

Today I read a blog post from 2006 regarding the use of MS Project as a tool.

Post Here

I responded with the following comment, which I think redresses two issues with Waterfall and Agile:

While I agree that MS Project is not the right tool to use for iterative development, it's purpose is well known by those people who use it. Since large infrastructure projects have multiple dependencies (e.g. building a large office building or airport terminal) with lots of resources, a tool like MS Project is almost mandatory. Sure, you can maintain all the aspects of a classic project (Plan, Execute, Control, Monitor and Close) in other tools, nothing really keeps the project's status visible like MS Project does. If anything, depending on the size of your release plan, you likely can find some benefit to use MS Project for an executive summary tool, and then use a spreadsheet, index cards or something else to do the iteration planning.

The primary reason I chose to respond to this post was because of the multiple quotes about how Waterfall is a bad methodology to use for development. At best, it makes our practice sound immature, since other project management practices embrace the idea that you "use the right tool for the job". More importantly, at the end of the day, there ARE projects that Waterfall is good for, and we as project management professionals need to be aware of that scenario so that you properly return value to your business.

Agile and EPM Live, Part 1

2010-04-07T14:37:00.002-04:00

As a company becomes more proficient at using Agile as an execution methodology, they typically realize that their planning and strategy needs some work, and this is where Enterprise or Portfolio Project Management comes in. Today, I am working with a customer who is facing this challenge and is trying to figure out what software might help them tackle the tracking aspect of their prioritization activities.

To that end, one company that seems to have a solution in this space is EPM Live. I am currently evaluating their software to determine if their recent foray into the Agile space will allow them to be an effective tool for the Agile Scrum practice. For some time, they have been a good tool for customers who use the waterfall approach to software development. It now appears that the Scrum story templates and backlog functionality of their product will allow an Scrum Master or Product Owner to work with their development team in an Agile way. More importantly, the functionality in their product will allow a large organization to do the "resource shuffling" that a strongly matrix-ed development business would want to make the most of their development resources. When the "resource-constrained" product owner group is able to see and change the current assignments of their development resources, they become more effective as the trusted partner of the business. And when that happens, software is delivered even more efficiently and aligned with Agile best practices.

With that said, I look forward to continuing to evaluate EPM Live. Stay tuned for more experience reports as I write them...

What Jack Bauer can teach us about project management...

2010-03-30T12:01:00.007-04:00

If you are like me, the news that this is the last season of the Fox show 24 was hard to hear. After watching the show since its inception, I have come to treat it as part of my annual January transition to watching regular TV, and I will miss seeing the main character Jack Bauer week in and week out. (I recently read an article talking about how effective that Kiefer Sutherland, the actor that plays Jack Bauer, is at handling interviews but that is for another post. Today I want to talk about how good Jack Bauer is at being a "project manager". If you are thinking, "say what?", read on...

In project management, organizations such as the Project Management Institute (PMI) encourage project managers to be "large and in charge". If you are a PM, you know is not an easy task. This is where I respect some of Jack's practices, and I encourage PM's to do the same:

Aligned with the Business Champion: On the show, Jack knows that he works for the American people, and that his actions must always align with what is in their best interest. Whether deciding to torture a subject (which we know to be ineffective) or escalating his concerns to the President, he is always thinking about what would best benefit his key stakeholder. Sometimes, we are PMs become conflicted about how we should best support our customer's needs, but if you have done your homework, and have a stakeholder registry which clearly spells out your stakeholder measurements of success, you can be a good shepherd of their requirements.

At a recent presentation that I attended, the speaker actually encouraged PMs to have a second registry, which told the PM what the "unspoken" requirements of their stakeholders were, but most of us don't work in environments large enough that we need this formality. Just remember that at the end of the day who you work for, and what makes the project successful for them, and you will have the answer to most of your questions about what would your stakeholder do (WWSD?).

Staying on Mission or Plan: Jack Bauer has one mission each twenty-four hour period, and generally this is to save the American people from a catastrophic event. As he approaches each hour of the day, this mission is always at the top of his mind. Regardless of whether he has a girlfriend who has gotten in trouble (Audrey-Season 5 or Renee- Season 8) or his daughter has been kidnapped (Season 1), he knows that this is a distraction, and he treats it as such. While in the end, he deals with each of these distractions in due time, as we all must in our project execution, he never fails to "stay on plan".

This lesson is an important one for PMs, and even more important one when you are work within an iterative execution methodology like Agile. Often we allow stakeholders to change the well thought out plan that we began our project with, and these changes often do not have the same risk and project impact analysis associated with them that the beginning of our projects had. As such, we execute these changes and fail to manage the impact of the change properly. This results in missed budgets and delivery dates. As PMs we shouldn't stop changes from happening, but rather manage them through adequate analysis and communication. If something goes awry, all the stakeholders are prepared for it, and if proper risk and change management is done, a plan to deal with the problem is in place.

Doing the Right Thing: While Jack is moving through his day, he has occasions where he is not able to communicate with all his stakeholders (e.g. President, CTU Director, etc.) and during those times, he has to make a decision that he thinks is most aligned with his customer. (The PMI actually has a question on the PMP exam that asks about this specific scenario, albeit without the 24 reference.)

When you are the PM, you are "large and in charge", and so times come up where you will have to make a decision, and you will not have the benefit of your stakeholder's direct approval to codify the decision. As such, it is important to know what your stakeholders measure the success of the project, and what you are empowered to do. A good plan, or charter document will help you determine these things and give you a blueprint for the decision process.

After making the decision, Jack always communicates with his stakeholders, and you should too. As those of us who have been doing this for a while know, sometimes an email is insufficient, so you should endeavor to communicate face to face, or at least by phone if the decision was an important one. (As an aside, I highly recommend you consider the message and the recipient often in your practice and constantly reevaluate how your messages should be delivered.)

So, that is a few examples about how you can "save the world" as a PM, or at least do a good job. Here's to the last few hours of 24 and being a good Project Manager.

For those of you Agilistas: It is notable that you could exchange out the title PM for Scrum Master, and the post would still make sense. I really am encouraged by how the Agile community is moving towards good PM practices and aligning to the idea that classic PMs have a place in the Agile world.

Control Chart Retrospective

2010-03-23T10:27:00.000-04:00

Recently, I have become enamored of business management practices that are typically associated with Six Sigma and lean practice. One of these is the use of control charts, and this week, I used this idea to drive my team's Agile retrospective.

(For those folks unfamiliar with the idea of a control chart, I have added a link here.)

Essentially, I used the stories that my team worked on this week, to drive a "feeling" score with a range of -2 to +2. We then tracked these stories across a time line of Monday through Friday and I looked to see if we had any insight that could be drawn out of the order of the stories and their impact on the mood of the team.

In our case, we noted several times where we had several stories in time sequence that were trending towards too positive (+2) or too negative (-2). Additionally, we had several that were in a row consistently in the positive or negative territory. If you follow 6-Sigma practice, you want to be sure that these events don't happen too often, or your process becomes "out of control".

I correlate this experience to people management. As a Scrum Master, one must ensure that the team doesn't get too "high" or too "low", because it can cause problems with the execution of stories. More importantly, Agile stresses consistent flow, and when you have teams that are too positive/negative, you can end up going towards peaks and valleys in code production.

If you are interested in trying out this idea, send me an email and I will give you more insight into how I led this retrospective. As with everything, results may vary, but in our case this week, we had good introspection into our iteration.

Hacker Disables Over 100 Cars Remotely

2010-03-18T10:00:00.009-04:00

Link to the Story on Wired

For starters, this is not a hacking event. The person in question used another employee's password and then set about "vandalizing" cars. That said, my first question was, "Where is the robust authentication process that a system like this should require?" If you are going to give a business the ability to remotely disable a vehicle, shouldn't that process be protected with something more than a password? (e.g. Give a RSA token with a substantial deposit to make sure that the businesses recover it when an employee leaves and protect the value of them.)

That said, I am going to bend this post a bit towards the Agile world. Often times, people argue that the interative approach that Agile uses for software development is not sufficient for mission critical applications. I think a story like this shows that regardless of how you choose to EXECUTE your project, you still need to have appropriate risk and scope planning to ensure that it is not misused. At the end of the day, you can use any methodology to make this kind of mistake, but in my mind, Agile is really best for ensuring that the requirements are tested, accepted, and delivered on time.

Agile and CMMI, Part 2

2010-03-16T13:59:00.003-04:00

A few weeks ago I wrote on the topic of CMMI and pairing it with Agile. Apparently, there is a smarter man than me, as Jeff Dalton has already put together a presentation on the topic and more specifically, his experience in making it happen.

Jeff's PDF presentation and the EventBrite event where you can find out more background on Jeff.

D.C. Business

2010-03-15T10:28:00.005-04:00

Recently an article in the Washington Post magazine recalled the "dot-com days" and several people's memories of what things were like during that time (http://bit.ly/bmo3C7). After reading the WaPo article and another one in the Wall Street Journal about the top 50 venture capital businesses (http://bit.ly/avX6du), I got to thinking about how the Washington metro market has transformed itself back to what it was during the 80's and 90's.

Back in the 80's and 90's, this area was known for its "beltway bandits" and the government contracting space. One of the notable things that happened during this time was that there was a substantial absorption of office space by the govt contractors which led to large amounts of speculative building. As the govt contracting boom began to slow down, banks such as Capital One (previously Signet Bank) faced large portfolios of non-performing building assets (20% or more). Soon after the contraction, the consumer wave that beget the commercial/dot-com sector, and that real estate became absorbed by the new commercial businesses.

For a commercial tech veteran like me, this was a good thing, because it looked like the area was becoming more diverse business-wise, and innovation seemed to be on everyone's mind. Now, business indicators are showing a market change.

As illustrated by the WSJ article, we have now seen a full reversal in the Washington metro area. There are no venture capital based companies in this area, which in my humble opinion points to a lack of technology innovation leaders, and when you add that to my unscientific observation about job opportunities in the market predominantly requiring govt clearances, it is obvious that we are back to the beltway bandit model. I personally think this is bad for the area, but with an push by the Obama administration to make government more accountable, perhaps we will see a more efficient government and conversely, more opportunity for commercial folks like myself.

Investing in What Developers Care About

2010-03-11T17:33:00.002-05:00

Today, I attended an Agile roadshow sponsored by Electric Cloud (http://www.electriccloud.com/), which was supposed to be focused on Agile practice and methods, but was more about the parts of Agile that we product owners don't often think about. Predominantly, it focused on Test Driven Development (TDD), code re-factoring, and continuous integration (CI), otherwise known as things that developers really care about. In reflection, it made me think about how little attention product owners pay attention to these sorts of things.

In my humble opinion, if an Agile team focuses solely on delivered value to the business, the development part of the team will become stale. As such, product owners need to embrace the technology that the developers are using to be sure that they allocate enough time in their iterations to the development team to allow them to explore new development tools and paradigms. I have done this successfully for four years with my current team, and with a recent conversion to Struts 2, I feel that my developers are happier for it.

CMMI and Agile

2010-03-04T16:05:00.001-05:00

One day last year, I was conversing with an Agile colleague about the idea of Agile and the Capability Maturity Model (CMMI), and how related the two could be. In short, companies that adopt an Agile approach to their software development are embracing a level 2-3 approach to development that could be part of their movement to an efficient software development practice. The interesting thing is that many folks identify the CMMI movement as being most aligned with Waterfall development practice, which I don't agree with. I think that any company that embraces a development practice and follows it's tenets, is on the path to CMMI Level 2 and the rest is all semantics.

That said, the "rub" will come when they are looking to use metrics to develop the feedback loop that is necessary to evaluate the success of their practice in the move to level 4. It is there that even Agile shops have difficulty because good metrics are somewhat elusive in Agile as the team is constantly re-factoring themselves to improve the ultimate deliverable, customer value. I would love to hear from any company that embraces both CMMI and Agile as I would really like to hear how the certification process went.