The conversation started with a history lesson by Ric Jackson, the Director of FIATECH. By my estimation, Ric (through the remarkable efforts of Nicole and Tara) is the maestro that always manages to pull off an amazing event and always manages to facilitate active and meaningful conversations. Ric moved the conversation into an insightful presentation by Ian Glendenning about his efforts to lead a task team that has been jointly endorsed and funded by FIATECH and POSC Caesar to spin up a self-sustaining business entity tasked with satisfying two primary business objectives. The first of these is to build an organization responsible for a reliable, consistent, and meaningful Reference Data Set (one of the foundation stones of ISO 15926). The second is to define and document a set of certification standards that can be used by the software vendors to benchmark their products by. These are both very significant and monumentally important activities. Some of the subsequent conversation centered around the notion that if a vendor supports importing ISO 15926 data they are supporting the standard in a purely commercial sense; however, if they support exporting data into an ISO 15926 data set then they are supporting the standard in a commercially risky way (because they are risking being displaced), but a way that is more advantageous to the industry AND the customer. This is a classic case of Chickens and Pigs. Those who support importing without exporting are really Chickens, simply INTERESTED in the standard. Those that support both importing and exporting are Pigs in that they are INVESTED in the standard. This concept was brought to light in the subsequent conversation when one of the owner/operators present provided a commentary on their journey with ISO 15926 and revealed a painful experience when her company engaged a software vendor to help move project data from an older system into a new system and was shocked at the response from the vendor. The unnamed vendor responded to the request by saying “We’re not in the business of losing market share” and, as I’m sure you can imagine, the response in the room was a combination of shock and disappointment as well as pragmatic recognition that this type of response is a natural response to the business environment surrounding the current state of the standard. So there it is, a hostage crisis. Hands in the air folks, this is a stick-up…and we’re holding your data hostage. Ransom can be paid in even numbered PO’s until you figure out how to fire me. Sigh…what a short sighted response…The dichotomy of the way that various parties responsed to her comment is simply an extension of the fact that there, currently, are more chickens in the room than there are pigs. The natural response to this situation for a pig is disgust and for a chicken is apathy. This spawned a dynamic and animated conversation that ultimately led to the community charging FIATECH with a mandate to get a definition of compliance and a framework for certification in place, and to get these things done quickly. The obvious 800 pound gorilla in the room was what, if anything, the software vendors are going to do to conform their existing work to these certification/compliance standards once they’re in place. One of the final points raised by Ric Jackson was that the definitions of compliance must be driven by the broader FIATECH community, including Owners/Operators, EPCs, Manufacturers, AND Software Vendors. This is a critical clarification because, ultimately the definition of certification/compliance as well as the activities to get the RDS service running are the only remaining hurdles before the standard will be in such a state that the onus will be on the operators to begin mandating or communicating a strong preference for vendors that can provide conformed deliverables. Once Ian Glendenning and the FIATECH efforts to move compliance and the RDS service forward are in place, we can only hope that the industry can figure out how to take advantage to the hard work that has been done; however, my guess is that this time next year the industry will be asking Mr. Jackson to pull the owner/operator members of FIATECH together to form a group that will mutually agree to put language into their project specifications that will “strongly prefer” vendors that can provide conformed turnover packages. Let’s just hope that Ian’s work can finally be the tipping point that makes the standard, well standard. One thing I do know is that we want to make the existing chinckens into pigs, and we want to reduce the amount of time it takes a new chicken to decide that they want to be a pigs. Breakfast anyone?

Mr. Lee posited a number of very interesting opinions regarding where we are as a society and where we are going. He started his presentation by introducing the notion of a “Cosmic Calendar”, which is fundamentally an analogy between an annual calendar (called a “Cosmic Calendar”) and the amount of time between the Big Bang and now. This analogy is very interesting and provides a lot of insight. The interesting details can be found at http://school.discoveryeducation.com/schooladventures/universe/itsawesome/cosmiccalendar/page2.html and, although he’s obviously biased in his beliefs regarding the existence of a higher power (guilt by association with Mr. Sagan-a reknowned athiest), it is an interesting perspective and further reinforces the argument surrounding the conversation that has been coined “the quickening”. In addition, he posited that life (conception) and death are poised to make the most significant change in history and, according to Mr. Lee, the future will involve parents being able to “choose” which traits their children will have and being able to choose the context of one’s death (or even more profound, the ability to choose whether to die at all). Needless to say, the both concepts introduce a number of ethical and practical concerns such as “if everyone can choose to live forever, how can the planet support the additional growth paradigm necessary?”. Interesting. Nothing more. Just interesting. The next part of his presentation was the crux of his message and the point was “Innovate or Die”. As Mr. Lee said, companies that don’t find new ways to accomplish things (as well as ways to accomplish new things) will not survive. He has a unique and interesting view of risk management and claims that every project should have risk review performed by a panel of enlightened individuals (led by a crusty-old pragmatist) that can recognize and vet which aspects of the project are innovative, evaluate the associated risks using a risk criterion, assign a risk index to each item, and finally use a traditional scoring system to determine if the overall risk profile is above the organization’s criteria. The risk criteria basically classifies each potential risk into one of 5 categories..
1) Reproduction – doing something that has been done before. This is the lowest risk and lowest form of innovation.
2) Optimization – doing something that has been done before, but modifying it to be more efficient or effective. This has some more risk, but since the foundation is reproduction, the risk is not very high
3) Enhancement – doing something that has been done before, but changing how it’s done. This further increases the risk.
4) Innovation – This is doing something that hasn’t been done before but is technically feasible. The risk profile for this activity is much more significant.
5) Miracle – This is doing something wildly innovative. Items in this category can be done but require many unknowns to fall into place in order to succeed. This is the highest risk.

If you take this scale into account when assessing the risk for for each aspect of your project, and score each one accordingly, then you should be able to assign a risk coefficient to your project and then be able to use that coefficient to determine whether you should proceed with the project or go and reassess the riskier elements of the plan. The mean tolerance that an organization is willing to accept should remain fairly constant if all of the risks of a project are collected and treated equally. If this is the case, then the process of vetting projects should be much easier by using a risk coefficient in this way provided that the risk analysis is honest and consistent across all projects (because the risk management team really needs to ensure that they are comparing apples to apples)

In all, Mr. Gentry’s presentation was insightful and engaging.

In case you didn’t know already Windows Vista has a screen capture tool built in called Snipping Tool. You can find it under your Start Menu -> All Programs -> Accesories -> [Snipping Tool]

So have you ever tried to take a screen shot of the pop up menu before? If you have you will find that if you try and print screen just the open window [Alt+PrintScreen] the pop menu will disappear.

You can do it with Snipping Tool.

Ok. Open snipping tool. When you open snipping tool your screen will fog over and you will be able to use your cursor to draw a rectangle to capture anything on your screen.

If you want to grab a drop-down menu, like when you right click on your My Computer icon. Open snipping tool and click cancel so your cursor returns to normal but leave snipping tool running, do not close it. Right click the My Computer icon and hover over the menu item you would like highlighted.

Now press [Ctrl+Print Screen]. Snipping tool is activated and your screen remains exactly as it looked when you pressed [Ctrl+Print Screen].

Wreckage of a downed British aeroplane, originally uploaded by drakegoodman.

Josh Nankivel at pmstudent.com asked me to write about some of the challenges and obstacles that we face in our environment. In order to do that I should explain a little about that environment. Over the past 36 months we have transformed ourselves from being a software development team in crisis to a strong team that is focused on delivering on it’s commitments. In 2005 we determined that the current approach to writing software wasn’t working. We were the poster child for “garage-band” style of software development, having inherited 1 million+ lines of classic (poorly written) ASP code [aka 1MLOC - I'll let you guess what the "C" stands for], and having very little recognition from corporate management that anything was wrong with the way things had been done. When I came to lead the group in early 2007, I had put in countless hours trying to lead the business toward implementing a PMO. While we actively maintain the 1MLOC, we have been working closely with a third party partner to replace the application. In parallel, we have a number of other small LOB applications that we have written using accepted best practices and design patterns. Needless to say, this means that there is a significant amount of churn and chaos when it comes to determining what’s going to be worked on and by whom. Enter SCRUM.

In early 2008 I approached the IT leadership and explained that an iterative and incremental approach to developing software was far superior, in our environment, to the code-and-fix triage approach to project management that had been promoted in the past and that this would be well suited to supporting the behemoth 1MLOC application while still allowing us to be agile enough to respond to the business’ needs in a timely manner. They bit.

So, what is our environment like, how do we handle some of the obvious gotchas, and what are the advantages/disadvantages to how we do business? Well first, I’ll say that this is what works for us, in our environment. I can’t speak to your situation, although if I can help, please drop me a line. Well, we currently have over a dozen product backlogs that are somewhere in the development/grooming workflow. We have roughly half that many Product Owners [none have been "officially trained", all have gone or are pending admission to the school of hard knocks] and the expectations of what it means to be a Product Owner are communicated loudly and often. Some gravitate toward the role, others are a little thicker and require some additional coercion encouragement. Regardless, we do the classic planning poker estimating that I described here and then, based upon our standing team velocity we let the Product Owner how much of the backlog we will be able to knock out during the next sprint. At that point, for any one of a couple reasons [the Product Owner needs more functionality than can be delivered in a single sprint/the team has some groundwork to lay in one sprint in order to deliver the key business deliverable in a second or third sprint/etc.], the team may decide that they need to deliver the next increment of work over several concurrent sprints. In this case, the backlog of backlogs is queried and the next product owner is queried for budget and schedule requirements [we may even look at the current state of that PO's product backlog] and a reasonable determination is made [by my boss and the IT Steering Committee] whether it’s acceptable to the business for the subsequent development to 1) be delayed 2) be preempted or 3) be split [deliver Sprint 1-Product A, then Sprint 1-Product B, then Sprint 2-Product B]…from the team’s point of view, this decision is somewhat irrelevant as long as the sprint backlog is ready to be loaded into the SCRUM Dashboard [which is integrated into the Microsoft Team Foundation Server - our source control and overall ALM solution]. Once the tasks are entered into the Scrum Dashboard (which is a lot like SCRUMY except that it’s tied to coding tasks, time tracking, check-ins, build events, etc.) the team tracks their own progress daily which automatically updates the Sprint Burndown, Product Burndown, BurnUp, and a hundred other reports that are hosted in the Microsoft SQL Server Reporting Services site that comes out of the box. The daily stand-up meetings are usually run by the team, as the ScrumMaster I sit in on them regularly; however, my prime directive is really just to make sure that they’re happening and that there are no discovered impediments that are/have not been communicated to me that come up as an outcome of the meetings. We have a weekly code review meeting for the whole team to see where we are, and we usually use this meeting to demonstrate the application state to the product owner. As part of our development team, we expect for the business to provide testing and QA resources so that we can be sure that the feedback loops are as short as possible.

So, you ask, what are the gotchas in this environment? That’s an easy list to start, but a very difficult one to call complete…so here’s my “easy list”…the hard ones will quickly become evident in your environment.

• Training Product Owners – especially in a “Command and Control” environment, it’s difficult to convey the concept and importance of servant leadership. Similarly, it’s hard to get “busy” business folks to commit their time to things that are commonly deemed to be unproductive
• Training Product Owners- getting them to understand the concepts of story points, estimating, life without requirements documentation and use cases, life without earned value, and ultimately the fact that the ROI and the “fit for purpose” functionality is their #1 responsibility
• Death by meeting – herding all of those backlogs, training all of those Product Owners, daily stand-ups, retrospectives, code reviews, “demo days”, Planning Meetings, not to mention the other “normal” meetings that one usually gets pulled into [weekly staff meetings, employee meetings, annual reviews, etc, etc, etc]…leads to about 80% of your time being tied up in one meeting or another…it really is hard to do a lot more than manage your schedule and check your business card to make sure it matches your driver’s license
• Leadership & Management – if your management doesn’t back you up and get out of your way, you will be tripping over one another. They MUST support you and then get out of your way. The proof is in the pudding…deliver a few times and they’ll get it.
• Tools & Co-location – We are one team, in one location. We tried the distributed team thing for a while and, to be honest, the requirements for the team to be available to meet to review something on very short notice makes co-location extremely difficult. Likewise, much like there isn’t really a “SCRUMBOK” because SCRUM is prescriptive as far as Engineering Practices, there are hundreds [if not thousands] of electronic tools for the team to use…a definite gotcha is the temptation to jump into the midst of the tools arena before you really understand the process that needs to be supported by a tool. We found TFS and SCRUM Dashboard….it’s what works for us….that means squat to you….make your process work analog, and then digitize it….I can’t say this any more clearly…learn to love the whiteboard, post-it, and index cards…worry about the business now and worry about the rest later [it might actually take care of itself].

OK. So there’s a start to a list…far from comprehensive, or even thorough. That list could go on for a while. So, to wrap up, you’re probably interested in understanding what are some of the pros and cons?

• PRO: We deliver working software, and we do it pretty frequently. This means that our Product Owners are pretty happy. Happy PO = Happy Business = Job Stability = Happy Employees = Better Software
• PRO: We get to deliver at a sustainable pace and we LOVE what we do. I hope that the death marches of 2006 are gone for good. We value people over process. Happy Employees = Better Software = More Projects = Job Stability = Happy Employees
• PRO: We get to be honest and transparent. With the PO on the team, there are no secrets about something taking longer than planned, or something not working as expected. The PO and the team get to figure out how to work thorough these challenges rather than worrying about doing damage control.
• CON: Estimating is really difficult, especially at first. Then, to make matters worse, budgeting is even more vague. For some organizations, this may be too much to overcome. I hate budgeting season…to ask me how much something is going to cost is to ask me for a complete and estimated product backlog, which isn’t terribly different than a preliminary project plan and schedule. Ugh. Budgeting Sucks.
• CON: If you are a “Command and Control”, “Do first, ask questions later”, “take the bull by the horns” kind of manager, you will really struggle with Agile. The CORE of Agile is in empowering the team, transferring that control to them, and settling into a support role….for a lot of folks, this will be impossible.

I was travelling the other day and I got a twitter message from a follower asking how familiar I was with SCRUM. I explained that we’ve been using it for a while now and that I’m modestly familiar with it. Well, it turns out that there is a college in Knoxville, TN called Fountainhead College of Technology and the professor has organized his class into teams and is tasking them with a project and expecting them to execute it using SCRUM. I thought “How awesome is that, I wish my college professors did stuff like that“, and then I got to thinking that I wish that ANYONE would have taught me these concepts earlier in my career. So….I thought that I would use this opportunity to invest my time into the lives of these college students in the hope that they will someday carry the little bit that I can teach them to new heights. I started down this road by writing the following document and sending it to their professor. I have to give attribution for almost all of the content to various sources I’ve encountered throughout my learning experience with SCRUM. Not the least of which is Ken Schwaber [who taught my Certified ScrumMaster course], Mike Cohn [via his excellent books], Tom and Mary Poppendieck in their book titled “Lean Software Development”, Robert “Uncle Bob” Martin in his various Twitter tweets and his great book “Agile Software Development” where he outlines the SOLID principles, Jeremy D Miller [The Shade Tree Developer blog], and Chad Myers [Los Techies] for their contstant banging on the SOLID drum and promotion of professionalism in the AppDev world.

Introduction to SCRUM

Ken Schwaber, one of the guys who came up with SCRUM, runs a company called ControlChaos. I got my ScrumMaster certification from him. His website is full of information about SCRUM…one of the best is a brief explanation of “What is Scrum?”.

First, you should understand that SCRUM is deceptively simple. It’s pretty easy to implement, but extremely difficult to master. Why? Because it challenges everything you think you know about project management. It is the complete opposite of Command and Control Project Management approaches [like PMP] and although it can fit into maturity measurement matrices [like CMMI], to me this is like putting cake icing on a rice cake. It has some value, but somehow it just “feels” wrong. Frankly, I feel that SCRUM is a close analog to the principles of Lean Manufacturing, and those principles have been modified and initially applied to software development. A good read on the subject is Tom and Mary Poppendieck’s book titled “Lean Software Development”. I also strongly recommend Ken Schwaber’s book titled “Agile Project Management with SCRUM”. You should note however that the most common technology application of SCRUM is in software development, but the approach can be applied to any complex activity that is likely to experience variability in the scope of work. On the other hand, projects that have a standard or rigid set of requirements that are not very likely to change are probably better suited to a waterfall methodology. Other technology projects can apply the SCRUM principles; however the largest body of knowledge relative to the implementation of SCRUM has been in the area of software development. As I’m sure you’re aware, developing software is highly dynamic and fluid, and as such is a prime candidate for deferring the scope and implementation details until the last responsible moment.

In my estimation, the power of SCRUM lies in getting the Product Owner involved in the planning and the execution combined with the iterative and incremental approach to delivery. A good analogy is the first trip to your girlfriend’s house…you may know the address, but you’re not exactly sure how to get there. The best way to get there is to get your girlfriend involved [sitting next to you is best], get an initial instruction [go to the corner of Maple and Patton], and to then incrementally and iteratively get feedback from her [turn right on Maple and go to the first stop sign, etc.]. Using the same analogy with a Waterfall approach, you quickly understand the benefits of SCRUM…in a Waterfall scenario, your girlfriend is only marginally involved, so you can only call her on the phone, get [and write down] directions, and then set out. You might make it to her house using the Waterfall approach, but if you get lost, or if there was something faulty with the instructions [either how they were communicated, or how you interpreted them], or if there is construction, or any of a hundred other potential scenarios….you’ll have to call her back and get revised or more detailed directions. In the first scenario, the probability of getting to the right place the first time is significantly better than the second scenario. If there are limited opportunities to get off track then the probability for success under the second scenario is improved.

In order to implement SCRUM, the first thing you need is a product owner that needs something. Next you get the product owner to describe what they want and what features it needs to have. These are called user stories, and a stack of simple 3X5 notecards is a great place to start capturing these. Don’t be too detailed, keep in mind that the purpose of the card is to get enough detail to remind you [and the Product Owner] what the feature is…in other words [stolen from Mike Cohn] the card is simply a reminder to have a detailed conversation about a feature, and the detail is intended to jog your brain. The cards should contain features that are important to the user, and nothing that is technical, architectural,  or implementation specific [Mike Cohn has written several good books on User Stories and Agile Estimating]. Once these “User Stories” are collected, the Product Owner should prioritize them. Next the team should review the stories and assign a relative weight in relation to the amount of effort required to satisfy the story. It’s important to have the product owner around when doing this so that they can answer questions that the team might have. Another common pitfall is for the team to estimate in some unit of time [days, hours, weeks, months, etc]…be sure to estimate in relative effort. I use the “dogs” yardstick…in our Sprint Planning meetings it’s pretty common to hear me ask if it’s a Chihuahua, a Jack Russell Terrier, a Blue Heeler, a Labrador Retriever, a Tennesee BloodHound, or a Great Dane…the team struggles with this sometimes, but in reality I think it’s because they want to estimate in units of time and I won’t let them. We use a technique called Planning Poker that is centered on the idea that the larger the amount of effort required, the less precision your estimate will have. If you had to guess how far it is [in centimeters] from the tip of your nose to the THIS word, you would be pretty accurate, if I ask you how far it is [in centimeters] from the tip of your nose to the nearest stop sign, you would be significantly less accurate, and if I ask you how far it is [again, in centimeters] how far it is to the Capitol Building of Tennessee [or Washington DC for that matter], you would be even less accurate. In order to express this in a consistent way so that the estimates are consistent, we use the Fibonacci numbers [I can’t remember which movie it was in…this famous sequence of numbers was in either one of the National Treasure films or the DaVinci Code]. If you’re not familiar with them, each subsequent number is the sum of the preceding two numbers…we start with 0 [for items that are so trivial that it requires almost no effort or is already completed], 1, 2, 3, 5, 8, 13, 21, etc…we use a deck of cards that I got from Mike Cohn’s company [Mountain Goat Software] and each deck of cards has four sets of cards that are a slight modification of the Fibonacci sequence, each set has ?[Unknown], 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, Infinity [too big to guess…also called an Epic]. The team usually sits around a table with the user stories and we play a “round” of planning poker for each user story…the players take their estimate and everyone plays it at the same time…if there is a consensus then that is associated with the story, otherwise the high and the low estimate gets to explain why they estimated the task would be larger or smaller…in many cases this is where the Product Owner is handy. Finally, once everything is estimated, you have to extrapolate a story to a period of time. One way to do this is to find something on the list that you have a reasonable certainty how long it will take, and then extrapolate that anything else with that score will take the same amount of time. Next you decompose the stories into tasks. The next step is to determine the length of the sprint [this is commonly a fixed period...2-weeks, 30 days, etc] and then taking the highest priority stories first, choose the items that can be delivered in the allotted time. Then every day, the team should gather for about 15 minutes to discuss what was accomplished by each team member in the past 24 hours, what will be accomplished n the next 24 hours, and what is preventing any tasks from progressing. This is not the place for a detailed conversation about problems, etc. The field is mixed on whether the Product Owner should attend the Daily Standup meeting…we ask our Product Owners to attend, but I gently advise them that they’re there to answer questions not to get a status update. During the Sprint, the Product Owner is allowed, even encouraged, to add, remove, or re-prioritize the product backlog [the items that are not under development]. At the end of the Sprint, the Product Owner, the ScrumMaster, and the team should critique the Sprint and collect from each person what went right, what went wrong, and what should change for the next iteration. Because of the very nature of a self-managing team and the interactions with the Product Owner, the communication throughput very quickly goes through the roof and the productivity, behaviors, and occasional friction that is natural in a healthy team become immediately visible to everyone involved. We call this “transparency” and it has a way of putting a spotlight on everything that is wrong, and it takes a non-trivial amount of maturity, honesty, and committment to focus your efforts on admitting to what’s wrong, finding a solution, and implementing it. This concept of transparency is why, in the words of Ken Schwaber, SCRUM is like living with your mother-in-law, it very quickly highlights everything that’s wrong and expects you to fix it. Warts and all.

Here is a great YouTube video called SCRUM in 10 Minutes… http://www.youtube.com/watch?v=Q5k7a9YEoUI

I also blogged on the basis of SCRUM…you can find it at http://pmstudent.com/implementing-scrumthe-basics-part-1

So there you have it, SCRUM 101. Be transparent.

I’ll give you some insight into our organization so that you can understand the political landscape. We are the IT function within a distributed Engineering organization. The Engineering group [ZEC] has offices in Amarillo, TX; Charlotte, NC; Denver, CO; Houston, TX; Minneapolis, MN; Omaha, NE; and San Antonio, TX. The Corporate HQ for ZEC is in Denver; however the core of the IT function is in Amarillo. The organization is distributed, meaning that each office is an autonomous entity that can perform every aspect of an engineering project [Design, Drafting, Doc Control, etc.]. ZEC is an operating division within a larger organization [ZHI] that is a full service Engineer, Procure, Construct [EPC] firm. ZHI has its own IT function and this blog will address some aspects of the relationship with this IT organization; however, the primary focus is the journey of the IT function within ZEC to become more adept and agile so that we can continue to bring the highest level of service and value to the company. The current technical solution set we’re using includes SCRUM, Team Foundation Server, Visual Studio 2008, MEF, Silverlight, Unity, Composite WPF, CAB, SQL Server, Linq, C#, ReSharper, SharePoint, ClickOnce, and a lot more. Most of what we do follows the MVP pattern and we’re HUGE fans of the Patterns & Practices team at Microsoft. In my experience, we are like most internal teams and in addition to the new projects, we’re also responsible for supporting a lot of old, crappy, legacy applications written [poorly] in classic ASP, PHP, and even Microsoft Access by folks who are no longer with the organization.

It’s all about stewardship. We, as IT professionals, are entrusted with the company’s hard earned resources and it’s our responsibility to, just like we would in our personal lives, make sure that the company is getting the best return on investment. We do this by making sure that the investment is made in our employees so that they are motivated and highly effective, next we take that motivation and focus on doing things the right way, the first time. We actively seek to avoid technical debt, we regularly evalaute our work for “smells”…either organizational or behavioral, and we try our best to involve the business in the design, usability, deployment, and support decisions that we make. I’m not here to profess that we’re a perfect organization, like every organization I’ve ever worked in, there are dysfunctions and bothersome behaviors. The purpose of this blog is to provide a window into our approaches and solutions, both technical and interpersonal. I hope you find this of value.