by Mike Brown | Oct 7, 2014 | Ascend Blog
We recently had the pleasure of registering to attend MAGFest 2015. For context, MAGFest is a 4-day event where video games from all generations, including independently (indie) developed video games are exhibited. There’s music, parties, and a great artistic outlet for many folks. If this sparks your interest, information can be found here: http://magfest.org/howtoattend.
So, after speaking with several folks who have attended MAGFest in the past and have been involved in the Video Game development community for a while, one of the highlights of MAGFest is the Indie Showcase. The Showcase provides Indie Game developers the ability to demonstrate their sweat, blood, and tears to the world. I’ve attended several Indie gaming events in the past, and these are by far some of the coolest folks I’ve ever met.
From a guest perspective, I can definitely think of several items I hopefully get to see when I visit in January. I know it’s a little far out, but man I cannot wait to see what they’ve accomplished!
- Xbox One & PS4 Indie Development: Since Microsoft and Sony opened their doors to be more Indie friendly with their new platforms, several new titles and platforms have been developed. Now over one year later, it’ll be interesting to see how developers have leveraged the new graphical and gameplay capabilities built into the next gen.
- Mobile Indies: One of the largest platforms for playing video games are already in our hands. The iPhone / Android platforms both have a large amount of mobile video game applications. Unity along with other gaming frameworks provides the ability for developers to develop and transfer their games onto mobile platforms. Without of course having to do all that awful objective-C programming!
- Indie Panels: More indie panels and discussion boards. Fostering a community of indie developers and indie gamers is important for the future of video games. MAGFest already does a great job at this, and we’re hoping to see more panels / discussions / happy hours.
All in all, we thinks this is going to be a great show and would not miss it for the world! Looking forward to seeing you all in January. Bring a coat!
Logo Source: MAGFest
by Mike Brown | Sep 20, 2014 | Ascend Blog
I’ve been in several IT projects where the client controlled, or attempted to control every aspect about the project. They are the client, and they deserve a say in the project, especially since they hold the purse strings. However, I’ve often seen times where the client dictates the vision when not really understanding the technology, openly argues with consultants / managers over failed delivery, and just plainly gives people a headache.
This relationship goes both ways, with the consultants often times exacerbating this relationship by providing unrealistic deadlines, limiting communication to monthly progress reports, or withholding information from their clients. This client – consultant relationship goes both ways, but it can be salvaged. How can you prevent your team and the client becoming antagonistic towards one another? Well, using an Agile Methodology in your projects is something that definitely helps. Here are some ideas around how to use Agile and some of its project management tools to establish or improve your relationship with your client (or suggestions you can give to your consultants).
Open Communication
Many activities in Agile Project Management are meant to be open, with lots of communication involved! Opening up your Sprint / Release planning sessions to the client allows your client to see what your team is working on, the major milestones coming up, and the core team dynamics. With this level of open communication, the client sees the total picture of the development effort. Using tools like JIRA, Trello, TargetProcess, the client can see which tasks are assigned to specific resources, and how they are progressing along.
Check Points
Monthly reports are a little too few and far between, especially when you are in crunch time. Establish a weekly check point where you sit down with your client and speak to the core milestones. Discuss roadblocks and possible ways to get around them, highlighting the costs and risks of each approach. Include your client in your daily standups with your team, let the client see your progress on a daily basis.
Be Up Front, Communicate your Shortcomings
If you are going to be late, communicate this immediately and effectively to your client. Do not let the deadline come up unexpectedly. Internally, review your project schedule every week and see where you are in completing your milestones. Functionality which may not make it to this release may be negotiated to get to the next release.
Stop with the blame game
Teams need to stop looking inwardly asking the question “Who is to blame?” If functionality is not delivered on time, it is not one resource who is to blame, it is the team. It goes across the management level to the developers, analysts, and testers. Resolve issues internally before they go over to the client, and develop a team which is self-managed and accountable.
Conclusion
So what’s important? It’s communication to your client and having a relationship where surprises are communicated up front, and the team works together to achieve a common goal. Involve the client (and clients…you should know when you are too involved) in your standups, sprint calls, and release planning activities. Open communication, above and beyond that Monthly Status Report and the Mon
by Mike Brown | Aug 15, 2014 | Ascend Blog
In 2004, three of the largest and hottest video game titles were released to the general public, all with similar, yet very different next generation engines. Game engines provide a framework for the graphics and overall abilities a video game may be able to handle. These engines in particular would go on to define an entire era of Video Game history, and spawn the next generation of video gaming graphics, abilities, and eventually leading to the large indie video game development community that exists today. The games I’m referring to are Doom 3 (id Tech 4 engine), Half Life 2 (Source Engine), and Far Cry (CryEngine 1).
The id Tech 4 engine was made famous for its implementation of “Unified Lighting and Shadowing” and “MegaTexture”, providing graphically rich environments and beautifully lit on screen objects and characters (particularly those blood splattered monsters). While this engine was re-used for several other id titles (particularly Wolfenstein), it would remain the weaker of the engines, lacking some of the abilities the other engines would later feature. I still thought Doom 3 was fun, smacking zombies with a flashlight always left me satisfied.
Source Engine, which powered Half Life 2, Counter Strike (Source), Left 4 Dead, among others was one of the most popular and powerful engines of its time. Its main differentiator was not only the advanced texturing, but also the frighteningly realistic physics engine. The engine brought to life untold of horrors in Ravenholm, blew terrorists across the screen in Counter Strike, and of course blowing chunks out of zombies. I’m not sure how many times I wanted to pick up a can and drop it into the trash can at the beginning of HL2, but wow was that an amazing introduction!
CryEngine 1 was originally developed as a technology demo for the Nvidia video cards being released in the early 2000’s. Eventually, folks saw the potential and turned it into a full-fledged gaming engine. The CryEngine, responsible for Far Cry 1, promoted the High-Dynamic Range Rendering (HDR) functionality and per pixel shading, providing the ability to render complex computer graphics.
While everyone has their personal favorites, there’s no doubt the Source Engine made strong headway into the gaming world during this time, and went to define a generation of game play. Developing for many of these engines often required a lot of hardware and an experienced team. While many indie developers eventually received some access to these engines (now they are available to the public), they were normally reserved for modifying the existing video games already built on these engines.
It”s interesting in how just one generation, many developers have become more open with their technology, enabling the growth of indie video game development. Compare these engines to Unity3D. While Unity3D lacks some of the bells and whistles, the openness Unity3D emphasizes provides greater outreach to gamers and fostered the growth of the indie gaming community.
What are you looking for in the future? Improved lighting? Physics? Or the ability to quickly pick up an engine and use it to build the next best seller?
by Mike Brown | Jun 21, 2014 | Ascend Blog
Choosing a Video Game engine is an important step in developing and releasing a new video game. The Video Game engine is a software framework, a collection of development tools and reusable components to put together a working game. Using a gaming engine saves time, money, and allows the developers / designers to focus on their ideas taking shape, not actually developing the engine itself from scratch.
Recently, we (Jake and myself from Ascend) began taking a look at various video game engines on the market a user may download and begin using to develop / design a video game. We defined some of our criteria for what a game could do ahead of time before making this decision. We decided we wanted our game to be:
- Widely Accessible and Playable on a Mobile Device
- Include minimalistic graphics
- Built on top of a common programming language
With these criteria in mind, we began our search for the gaming engine which would help put our vision together. We came across three main engines currently hot on the market:
- Unity3D
- Unreal (UDK)
- Cry Engine
The increasing number of Independent (Indie) game developers has led to many companies releasing their gaming engines on the market and (often times for a fee) allowing indie developers to download, install, and develop a game using the engine. Physics is another key factor when evaluating a game engine, for instance if your character throws a bottle, how does the game capture the action of throwing the bottle, the bottle falling, etc. Below lists key points of each of the gaming engines, and how they relate to one another by comparison:
Unity3D:
- Price – Free to download and install. But add-ons, features, and the professional edition may run up to $1,500 or more.
- Graphics – Decent. Can do 2D and 3D, but the graphic details are not as strong as other games.
- Physics – Excellent. Built in physics engine
- Programming Language Used – C#, very widely used and easy to learn OOP language.
- Royalty Payments – None until you make some cash ($100,000)
Unreal UDK:
- Price – $19 per month to rent, $240 total price with one license which can be used in an entire company.
- Graphics – Amazing. Simply breathtaking.
- Physics – Excellent. Built in physics engine
- Programming Language Used – Native script, difficult to learn.
- Royalty Payments – The page crashed when we looked (haha)
CryENGINE:
- Price – $10 per month.
- Graphics – Fantastic. No Mobile capabilities though yet.
- Physics – Excellent. Built in physics engine
- Programming Language Used – C++ / C# / LUA. CryMono (C#) is commonly used when starting out.
- Royalty Payments – None from what we can tell (woo hoo!)
Please note, some of these factors / dollar amounts may have changed since this was last visited / published.
After looking at the three engines in detail, we found Unity3D to be our tool of choice. Its ability to easily port to a mobile device, loads of documentation / tutorials, and use of a common programming language (C#) led us to use this gaming engine as our framework. While we do are not getting the full emersion / details allotted by other engines, Unity3D is built for beginners to learn the ins and outs of developing a game. It’s much more forgiving than Cry or UDK.
What are your thoughts? Do you have a favourite gaming engine?
by Mike Brown | May 2, 2014 | Ascend Blog
The Project Management Body of Knowledge (PMBOK) defines risk as an uncertain event or condition. If it occurs, it may have a positive or negative impact on the project or product being developed. Organizations perceive risk differently, either they are risk adverse or risk attuned. So, how does Health IT fall into all of this?
Health IT, by a complexbeast to tackle, it not only requires a high degree of technical skill, but also a good handle on policies and laws in place to ensure technology developed is compliant. in Health IT projects is not just at the product level, but often involves or impacts many stakeholders. Ensuring that the project takes maximum advantage of those risks which may have a positive impact while mitigating those risks which will have a negative impact is important in a complex Health IT project. I would like to call out three main factors when it comes to Health IT project risks: a project manager must plan risk management (as the PMBOK says), capture and monitor risks, and communicate risks to stakeholders.
Planning how to perform risk management is important, consistency must be maintained throughout the project to ensure risks are captured, managed, monitored, and updated in a coherent manner. These ideas must be enforced throughout the project, and documented in the risk management plan. Brainstorming sessions, interviews, etc. must be captured. With all the Health IT policies and technologies floating around, having a good, consistent way to tackle hurtles presented by risks is key to success.
Capturing and monitoring risks allows for a project manager or project team member to capture project risks found, update those existing risks, and provide a risk strategy. Many times, risks are captured in a Risk Register, a centralized area where all risk information is captured. Risks may have Probability / Impact analysis, Qualitative and Quantitative analysis performed on them as well. Risks must also be version controlled, when a risk is updated, changes must be captured. This is not only true for Health IT projects, but any projects.
Finally, risk communication is key to project success, what good is a risk register if no one can access it? Doctors, nurses, billing specialists, etc. must understand risks and weigh in, as they will be the main users of these systems. If these are mission critical systems, regular meetings with stakeholders is important, and risks should be communicated up and handed. With the Healthcare.gov project, many times risks were not communicated properly, and we saw where that landed.
Health IT Project Risk Management is an important aspect to managing a Health IT project, made more important by the growing complexity of implementing a healthcare system.
Be sure to check out our seminar co-hosted with the PMIWDC chapter to learn more about Project Management and Health IT: https://www.pmiwdc.org/2014/05/educational-seminars
Image courtesy of Washington Post
by Mike Brown | Apr 23, 2014 | Ascend Blog
In a lead up to my Health IT and Project Management course, I wanted to dedicate a blog post to Health IT and why these initiatives need competent and passionate Health IT Project Managers.
As spending on Healthcare and Health IT continues to grow, so do the number of jobs in the Healthcare industry. Many of these projects and initiatives are complex in nature, and require a great deal of technical and policy knowledge to implement. So, what does this mean for the folks leading the charge? Where are we going to put our $2.8 Trillion (trillion with a “T”)?
There is a theory made popular in the 1980s that a manager did not need to understand the work being performed, only how to manage employee. In stark contrast, the complexities of Health IT require a project manager not only have a strong understanding of the technology being implemented, but also understand regulations, policies, and possess a strong passion for Health IT.
Understanding existing policies and regulations is an aspect of being a great Health IT Project Manager. There are many regulations and policies on the market a healthcare product may need to comply with, should it fall under a certain line of healthcare work. The Health Insurance Portability and Accountability Act (HIPAA) standards must be upheld through strict security measures to ensure patient information is secure. The Health Information Technology for Economic and Clinical Health Act (HITECH) pertains to improving healthcare quality, safety, and efficiency of healthcare delivery. Finally, Meaningful Use (MU) possesses multiple stages in order to enable, digitize, and transport patient records among multiple organizations. This is a small subset of many regulations with cool acronyms. There’s even more, and the Health IT Project Manager needs to understand what they mean, and how they could impact their project.
Many of the healthcare technologies on the market today use a myriad of standards and must communicate (or interoperate) with one another. Any gadget today on the market, whether it be an iPhone, Google Glasses, wearable / portable technology can be leveraged for Health IT in some way. The Project Manager needs to have vision, and understand how technologies today can handle Health IT.
Finally, a Health IT Project Manager must have a passion for healthcare or health IT. Having a story and a reason for working in Healthcare provides motivation for both the Project Manager and the team. What is your passion? Why are you in health IT? Answering these questions and understanding your motivations will allow you to be an effective project manager in a complex industry.
Project Managers need to make sure the project is completed, but they also need to be leaders. Health IT needs its leaders.
To learn more, please come by in May to attend our all-day session co-hosted with PMIWDC on Health IT and Project Management here: https://www.pmiwdc.org/2014/05/educational-seminars.
Hope to see you there!!!
by Mike Brown | Mar 29, 2014 | Ascend Blog
Many organizations rely on heavy documentation for requirements, architecture, testing, and implementation. Often times these documents go largely unread, forgotten and exist for the sole purpose of creating a legally binding document between the IT department or consultant, and the business or organization. Iterative development, and defining solutions with close involvement with the customer is key to the success of an Agile project.
In a way, a Requirements document may be used by the business as a means to state the contractor or IT department did not exactly do everything which was written in the document. My question to that is, so why do we have a requirements document? Is it a deterrence in case an IT Department does not do what they were supposed to do? These documents go largely unread, and the development team is often confused by what is stated in the requirements, leading to longer development time and time to market.
Recently, I’ve had the chance to work with simulation software with several colleagues. Many software applications today are web applications, built using a standard n-tier architecture. At the top of the tier is the presentation layer (what a user sees), in the middle is the application layer (when a user clicks an element in the presentation tier, what it “does” is defined in the application layer), and the bottom is the Data Tier (stores all interactions, information, and interacts with the application layer).
The user (and often times the customer) only sees the presentation layer. So, why not build that first? Your business customer wants to see a solution, help mold it, shape it, and see what it will look like. The business logic is often times already defined; it is the way the user interacts with the system which will involve the customer into the design of the solution.
Many simulation tools and Integrated Development Environments (IDEs) provide the ability to build out a custom user interface with some functionality. It can be built on the fly, quickly, and demonstrated to the customer. A development team can then take software developed in the simulation environment, and build out functionality and code behind the presentation code. This increases agility, providing the customer with a functional prototype which can be quickly built with a level of functionality behind it. Developers can take it, and understanding how the presentation tier works define the application and data tiers.
The requirements document is key to documenting all requirements, but often leads to a large, unusable document for the development team. Creating software within a simulation environment provides a method for IT departments to quickly deliver a working prototype and functional software. Ultimately, this deters the customer’s notions “I’ll know it when I see it.” Forward to Agile!
by Mike Brown | Mar 8, 2014 | Ascend Blog
What is it that an Enterprise Architect (EA) does? Why do we need EA’s? After these questions are presented, answered, elaborated, and elaborated some more, hopefully the executives will give in and say ‘go do your EA’. Now, what is the first step?
The importance of leaders embracing and understanding EA cannot be underestimated; aligning business objectives with technology allows organizations to make better use of their existing technology, providing a clear strategic, technology driven path going forward.
Technology enables the achievement of business objectives, a key statement applicable to the first steps in establishing a true Enterprise Architecture. Isolating the business goals and functions from the technology currently utilized within the organization is key in developing an enterprise architecture. A strong understanding of business requirements and objectives is required.
Discovering business objectives, drivers, and goals may be a complicated task when there is limited technology or a small, mostly operational / help desk Information Technology (IT) department. There are several techniques, both technical and non-technical an EA may utilize in obtaining and understanding business objectives. These skills and techniques are often used by Business Analysts today.
- Interviews: Interviewing key managers (CIO, CEO, CFO, CTO), leaders, and stakeholders provides a wealth of information on business objectives or goals.
- Company Mission Statements / Documentation: Review organizational documentation which may be found internally or externally. Different branches of a large corporation may be responsible for different business objectives or goals.
- OMB Guidance and Definitions: For Federal Enterprise Architecture, the Office of Management and Budget (OMB) provides guidance and definitions on various objectives and goals Federal Agencies posses.
Another, however lower level aspect which must be understood while establishing an Enterprise Architecture: the business processes undertaken to meet the business objectives and goals. Business Process Modeling (BPM) is an excellent technique to create Business Process Diagrams (BPD). These diagrams display a step-by-step process for achieving a particular business goal or objective. BPM’s are often completed using the Unified Modeling Language (UML) based Business Process Modeling Notation (BPMN) depicting flow elements, swim lanes, and artifacts utilized and completed throughout the execution of the business process.
From these, a Business Reference Model (BRM) may be created. The BRM is one of the most important artifacts in establishing an Enterprise Architecture within an organization. The BRM concentrates on both the functional and organizational aspects of the business and helps establish the Business Architecture.
Having a clear understanding of the Business Goals and objectives is important to establishing an excellent Enterprise Architecture, and eventually aligning business goals with Information technology. The technology supporting the business is then defined in the Technical Reference Model (TRM), Application Architecture, and Data Architecture.
What are your first steps to establishing an Enterprise Architecture?
by Mike Brown | Feb 15, 2014 | Ascend Blog
Many key differences exist between organizations which fall under the category of a “Non-Profit” or Association, and a For-Profit corporation.
Many of these Associations exist to unite a key group of members or employees in a specific industrial or government sector. For instance, the National Association of Realtors (NAR) unites Realtors across the nation. One of the main purposes of NAR is to encourage and advance education on Real Estate for both Association Members (Realtors) and non-members alike. Like many associations, NAR exists to further the cause of a specific industrial group, Realtors, and benefit home owners through educational pieces. The Healthcare Information and Management Systems Society (HIMSS) is another example of an association or non-profit, furthering the education and promoting Health IT.
With this in mind, it is not possible to approach an association the same way to approaching a For-Profit corporation. They possess an absolutely different business model and often times contain a very different culture from corporations. If consulting with a Non-Profit or Association and implementing agile methodologies, it is important to take the following into consideration:
- Meet the IT Department: Many Associations use Information Technology (IT) in more of a support role and purchase many COTS products. IT”s job at times is to simply keep the lights on. It is important to meet with the IT Department and work closely with them. As an Agile Consultant, you are a teacher, and take the time to teach and introduce Agile to the group.
- Gauge the Acceptance of Change: Determine how accepting the IT Department, and the business line is accepting of change. Many associations may be slow to accept change. If an organization is not ready for Agile, but is willing to accept slow changes, it may be important to start with a waterfall process and slowly introduce new ideas. Iterative Waterfall, Iterative, to finally Agile.
- Be a “Teacher” and Listen to Your Client: Associations are academic in nature, proposing new ideas in their line of work or certifications. When working with your client, be a teacher but also be a good listener. You need to understand their model and culture (which once again may be different from a typical corporate or Federal customer), and how to approach a problem.
- Take time to Work with the Business as Well: IT in many associations may be in more of a support or research role. Take time to also work with the business (those producing reports, content, marketing, or articles for the association). Determine what their pain points are in regards to technology and make note of them. Track your correspondence and information in a centralized tracker, matrix, or repository. This will help when speaking to IT and beginning to plan out changes to a widely used Corporate system
Developing this repertoire with both IT and the Business will increase your visibility in the association. While you are there to implement an “Agile” process, you will also begin bridging potential gaps between IT and Business, acting as an intermediary between the Technology and the Business needs. IT is about enabling and supporting Business goals, agile helps do it faster and better.
Be the Agile PM, but also be a teacher, leader, and intermediary and you can successfully establish an Agile Methodology in your association.
Is your association agile? What changes or technology pain points do you see which could be alleviated?
Image Source: Dreamgrow.com
by Mike Brown | Jan 25, 2014 | Ascend Blog
The days of the traditional CEO and organizational hierarchy within technology (and potentially elsewhere) are numbered.
I recently received by Certified Scrum Master (CSM) certificate after attending a class where a kind hearted geek spoke on the merits of agility and what it meant to be a ‘SCRUM’ master. Within an Agile team, software is delivered after multiple sprints, and incrementally built. The final product is consistently refined as new requirements are introduced, ultimately leading to a well-built piece of software. A SCRUM master is a member of a Project team (usually a lead developer or tester). The SCRUM master is there to enforce the Agile methodology, regardless of whether that person is a CEO, a Project Manager, or a fellow development team member. SCRUM teaches us about openness, focus, commitment, courage, and respect. We all fill a role, our salaries might be different, but at the end of the day there’s little ‘entitlement’. The team does what they need to do to “get to done” (complete the sprint).
If SCRUM and Agile are so popular, and organizations tout they are “Agile”, why are organizations….not? In a traditional hierarchical organization, team leads or operational managers report to middle managers, and middle managers (managers of managers), report to upper managers (managers of managers of managers), and so on. For software to go from development to testing, a bureaucratic process must be met before moving forward. Wow, that’s a lot of layers of just….reporting? Attending meetings? What do those managers really do?
To be frank, if an organization was really agile it would not be so hierarchical. Employees would not be reporting up, they would be reporting across. The Technology CEO should not be in hand waiving meetings, they should be working with their employees; ensuring tasks are completed on time and helping to guide the vision of the company or product. Agile has the ability to scale to large organizations, and is not used often enough. Passing papers around has to stop. We need to automate these procedures more and free up time for a manager to be a manager.
Long live Waterfall…I guess.
Maybe I’m just a naïve startup, but…you cannot underestimate the power of agile. Look at your organization, whether small or large. Is it truly as agile as it touts? How can you improve or instill agile into your organization?
Reference:
- The Agile Manifesto: http://agilemanifesto.org/
- SCRUM Methodology: http://en.wikipedia.org/wiki/Scrum_(software_development)
- Image Source: agilescrum.org
