After taking a great webinar from www.threebeacons.com and a good talk from Nathan Eror www.neror.com; I have a better understanding of Agile and how QA works in that team.  Using this information and the process of actually scoping an Agile project with my team-  I believe we have a general concept of how Agile works.

The first things we needed to understand were the words-  the jargon….  I have also learned that there are like 8,000 different ways to do Agile and every team takes what works from the best versions…
Release-  the actual final piece of software.

Iteration-  Time frame used to break up each development cycle within the entire release cycle.  Usually 1 to 2 weeks in length.  You want at least 4 iterations per release in order to take advantage of Agile methodology.

Epic-  It’s like a phase-  more like a block of functional pieces that are logically grouped together. Ex:  Login Page for Online Application

Story-  mini, functional pieces of the release within each epic.  Ex:  I am a Acme customer and I need to login to the Acme site with my email address.  Stories should be phrased as a functional need-  not CODE or DEV work.  Clients do not care about Tables and embedded graphics.  They want to see what works.

Unit Testing-  The heart of Agile.  Test everything as you build it.  Automate the testing if possible.

I will go into a whole different blog about testing-  I am sure I am about to learn a lot as I am being helped by a developer on setting up our testing, repository and bug tracking systems next week.

Basically what we learned is that Agile works if you sell it to the client as collaborative.  Your team MUST buy off on how iterations work and that everything- including testing and build deployment go into each iteration so that at the end of the iteration, you have a functional product for testing and sign off.   The product does not have to have all functionality, just what the client needs to provide a more defined scope as each iteration is completed.

We had to define optimal programmer hours available for each iteration.  We determined for our first project that we would sell 50 “points” for each iteration.  Those points were  based on programming hours and difficulty of each story.

That brings me to my next revelation-  you have to basically scope the project down to the story level before you can quote it-  so planning and pre-project fact finding is critical.  The idea is to pre-qualify the lead and plan the hell out of the project before you walk in with a presentation.  Then the client can shoot it apart through the Agile process by redefining needs.

I will post more as I get deeper.  What we have found makes Agile great for us-  although  a bit cumbersome for smaller projects.  We are finding our middle ground.

Walking through a simple technology rollout:

Let’s explore a relatively simple IT issue and solution.  Let’s look at how an IT manager might introduce the solution, project plan, implementation plan, training and maintenance of the new solution.  We can use the example of the Blackberry Enterprise Server (BES).

As the IT manager, your company has begun to move into new markets.  The company has begun to acquire smaller firms with a more disparate sales team.  Not to mention that as the senior executive have begun to meet with the newly acquired companies and explore other markets, they are traveling often.  The sales team and executives are missing out on critical communications because they are only checking email over their VPN connections on the laptops they carry.  Many sales people cannot get wireless data signal in some of their client areas and are out of the loop for hours at a time.

POP email is used some, but the security and overhead of the firewall and mail systems is making this an issue.  POP does not offer the option of calendar sync either.  People are clamoring for an easier solution.

BES is an easily integrated software solution that uses a minimum hardware set in order to integrate existing mail systems such as Microsoft Exchange in order to deliver email, calendar and tasks systems to handheld phones over the air with security and centralized management.  Research in Motion provides the following notes on BES:

• “Organize email messages that require follow-up with the use of flags, as they do in Microsoft® Outlook®1
• Easily access network drives using the remote file explorer directly from their BlackBerry smartphones*
• Open and forward calendar appointments, including attachments1
• Browse folders on the BlackBerry smartphone to view and attach files to email messages*”, (RIM, 2009).

With a need identified and a solid solution in hand, an IT manager should research the cost of the system and confirm integration points.  The cost of a BES server can be mitigated in many ways.  If there is already a virtual server farm in place, a new instance of a server would suffice and not cost more than the operating system license and the BES software and user licensing.  If there is no virtual server option, then a true hardware server may need to be purchased.  Hardware should be planned out based on best practices from the software vendor.

The software vendor will also discuss best practices regarding software interaction.  Blackberry Enterprise Server 5.0 will not integrate with Exchange 2000 or run on Windows NT 4.0.  If additional infrastructure upgrades need to happen, then these should be considered when designing the plan and understanding ROI.  For the sake of our project, we determined we need a new hardware sever running Windows Server 2008.  The existing mail server is Exchange 2003 and all smart phones are compatible with BES v5.0.

It should be stressed that no IT manager should ever present hardware and software for approval before creating a project plan for implementation.  Many projects are killed mid stream or after the hardware is approved but when the senior managers see implementation costs for labor or downtime.  A well defined plan should include hardware and software, hours and interruption schedules.  In order to gain approval, it may be necessary to project the lifecycle of the solution and discuss ongoing maintenance fees or costs for expansion of the systems past current capacity.

At this point we will provide a project plan for implementation of the systems that include a well defined schedule for milestones and possible break points.  Each break point should include a backup plan for fallback.  Fortunately, a BES install is relatively easy on interruption to production systems.  Once the plan is approved by the senior managers, it is time to consider training of end users before the systems are even installed.

Training should be geared toward end users and should focus on the key pain points identified in the scoping of the project.  If the majority of the users want to be able to wirelessly sync their calendars and integrate to a central mail system, then the focus should be on those feature sets.  It is important to begin to float documentation or provide lunch and learns before the technology is rolled out to everyone.  This allows people to get a feel for what is coming before it is implemented.  Providing ongoing training in the form of online content or additional training sessions is critical to ongoing adoption of the technology.

It is time to move on to implementation and support.  Implementation should be a time when all stake holders are well communicated with.  The best implementations are ones where you pull he tablecloth out from under the china.  No one should know you did anything.  IT managers should provide onsite or highly available support during the first 24-48 hours of a system change or installation.  This support provides a smoother transition and can often mean the difference between long term adoption of a new system and having vocal stakeholders upset with what was over all a very good deployment.  It is often said that if a completely new network was installed and it worked 98% perfectly in the first week, but the president of the company could not print, then the entire project was a failure.  Perception is reality.

The success or failure of a successful implementation creates touch points at many levels.  An IT manager must manager their technical staff to research, design and implement the right solution in a timely manner.  They must also communicate with internal and external stakeholders to confirm budget, ROI, design specifications and time tables.  Once all is said and done, end users must be trained and the systems must be maintained over time.  All of these factors must be considered and executed with little margin for error because of how the perception of the project effects its outcome regardless of reality.

Quick Study- System Development Life Cycle. Computerworld. Retrieved July 12, 2009 from http://www.computerworld.com/s/article/71151/System_Development_Life_Cycle?taxonomyId=011

Blackberry Enterprise Server v 5.0. RIM. Retrieved July 5, 2009 from http://na.blackberry.com/eng/services/server/5/benefits.jsp

Delegating Without Losing Control. TeamTechnology.co.uk. Retrieved July 5, 2009 from http://www.teamtechnology.co.uk/soft-skills/project-management-training-part7.html

Understanding the groundwork for a business technology deployment:

In order to manage a change in technology, there needs to be a clear plan in place before during and after the implementation.  The systems that are being changed will stakeholders in both the technical and non-technical portions of an organization.  It is important to remember that communications, planning and follow through are the keys to a successful change in any company.

There have been formal processes for how to handle these types of implementations in an organization.  The System Development Life Cycle (SDLC) is a good example of a process by which a technology is designed, implemented and supported through its useful life.  The SDLC has many iteration.  There is the oldest model, the waterfall which falls in line with many IT system deployments regarding infrastructure today.  This model is becoming outdated and is being replaced with Rapid, Spiral and other deployment and upkeep models.  “The synchronize and stabilize method combines the advantages of the spiral model with technology for overseeing and managing source code. This method allows many teams to work efficiently in parallel. This approach was defined by David Yoffie of Harvard University and Michael Cusumano of MIT. They studied how Microsoft Corp. developed Internet Explorer and Netscape Communications Corp. developed Communicator, finding common threads in the ways the two companies worked,“ (ComputerWorld, 2009).

Regardless of the deployment methodology, there must always be a findings phase at the beginning of any project.  The client or customer must be interviewed to understand what the need is.  There is almost always a business need that must be addressed.  The core of any IT systems deployment is a business need.  It is critical that technology not be implemented for the sake of technology.  IT professionals should listen for pain points and find the needs for their clients and customers.  The need to track documents through a manual audit may be streamlined by tracking the physical papers with a bar-coding system.  A client may need to be in touch with vendors regardless of time or location.  Tracking of issues in real time with automated auditing and archiving may be a need for an oil and gas company due to high levels of uptime and statutory needs for their industry.

All of these examples provide an IT manager a juicy opportunity to install backend communications systems for knowledge workers or relational database systems for multi-application integration and data analysis.  The business needs are very clear and the ROI for these systems is evident and relatively simple to calculate.

Once the need is identified, then the project manager must take the time to identify the appropriate technology to solve the issue.  Many times the issue will be found straight from a vendor.  Installing a Blackberry Enterprise Server will allow a company to seamlessly integrate smart phones to their existing email systems for the sharing of email, calendars and tasks.  The challenge for an IT manager is when there is an existing system or systems that require creative integration.  Taking a proprietary application or legacy database and allowing a newer system to integrate for a seamless deployment can be very difficult.

In the next blog we will look at an example of how to walk thourgh an actual deployment.

The formation of a scalable- functional AppDev department…

We are redefining our Application Development business line.  I have been asked to head up the efforts to sort out the bodies and set solid direction.  There are so many places to look, so much to digest.  I believe we have been able to break down our needs into a few core pillars:

• What is our development philosophy
• What SDLC model do we use
• What type of work are we looking for
• What skill sets does the team have
• What skills will we need
  • Now
  • Next year
  • In 3 years
• What tools do we use to:
  • Code
  • Define Scope
  • Communicate with clients
  • Define and track projects

We are currently trying to understand the difference in SDLC and development philosophy.  I am not sure what the difference is in Water Fall vs. Agile.  We understand the concepts- I would think Agile is a philosophy where Waterfall is a methodology for execution. 

It is apparent that our current project tracking systems in Connectwise were not built for the type of projects an application development team executes.  We would like to explore Base Camp and some other interactive, web based project management systems.

One of the most important parts of this will be the examination of our team and what they can do.  In order for the rebuild to work, we will need to focus on the abilities of the team and define where we can generate the most opportunity for our dollars.  We absolutely need to get a skills inventory from each member and focus on how that will define the line of business. 

Very exciting-  More to come….