Where do solutions come from - our first release

11 months ago | Mark Mintz: Mark Mintz

In previous posts I wrote about an initiative we are working on to change the way we engage with our users. Our first release toward this goal is planned for the end of this month and the team has made great progress and will achieve our release goals. Our goal for this release is to begin seeding a virtual community space (a simple blog for now) with content to help people visualize what the community can be. Our thinking is that if the content is compelling people will begin gravitating to it. When this happens we can have a set of people that feel strongly about the content and the forming community that we can then work with to help determine how best to evolve the platform to meet the communities needs. As we provide better tools we hope to have the community take over and move forward on their own. Once the community takes over, openly discussing how they work and sharing ideas with each other, we can hopefully learn more about what truly matters to them and find new and better ways that IT can impact the way they work.

Value in simplicity

about 1 year ago | Mark Mintz: Mark Mintz

In looking through my Twitter stream the other day I came upon an interesting tweet from Andrew McAfee pointing to an article in Wired titled The Good Enough Revolution: When Cheap and Simple Is Just Fine. It's an extremely insightful read, especially in light of the work I referenced in my recent posts around finding solutions to user problems. If I could sum up the article into a key takeaway it has to be the paragraph below:

What users really need

about 1 year ago | Mark Mintz: Mark Mintz

I came across this blog post entitled "What is User Experience Design" by Alla Zollers a PhD student at UCLA in the department of Information Studies. The post is the authors quick overview of user experience design. In reading through it I came to the following section that highlighted exactly what we are trying to achieve with the initiative I highlighted in my previous post, Where do solutions come from?:

... when Henry Ford built his first car, he was quoted as saying “If I’d asked my customers what they wanted, they’d have said a faster horse.” A company’s job is not to give users what they want, but to solve problems. The problems that companies are trying to solve are usually social, and so understanding people and how they interact with each other and their environment forms the key understanding and driving force of the product design and direction.

At the core, user experience advocates for the end-user and makes sure to bring the customer’s perspective into the decision making process. In order to achieve this user-centered approach, user experience designers engage in several activities:

• Observe customers in their natural environment to understand how they are currently interacting with existing systems, as well as get insight into how users view the world (their mental models).
• Build empathy and understanding of the customers within the entire product team

The rest of the post goes on to provide more insight into User Experience Design and it's business benefits, but it is the section above that I believe truly explains exactly what we are trying to do.

Improvements in application support - update

about 1 year ago | Mark Mintz: Mark Mintz

In late 2008 I worked on and blogged about an initiative to improve our application support function. While that initiative has been successful in implementing a new way of supporting our applications and we are in the process of moving our applications to the new model there is something else that I would like to acknowledge. In addition to testing the changes that I described in my blog post last year we also implemented some large changes in our existing support team to more immediately address the same issues I described in the earlier blog post. These changes entailed streamlining the team and asking them to shift their focus from "fire fighting" to:

1. collaboration and learning
   
2. root cause analysis
   
3. continuous improvement
4. making support a fun place to work
   

The idea was that we had some quality issues with our applications and our application support processes and the quality of service our users were receiving was impacted. We wanted the support team to identify the root causes of those issues and work with our development teams, other support organizations and sponsors to address the issues and make our applications more supportable while also making application support a place where people are happy to work. Well it's been about a year now, the team is in it's fourth "release" and there were some interesting things presented at today's sprint review:

1. the July year over year support ticket volume has decreased by approximately 30%
2. the first item presented by the team was the number of hours of support team member savings per month that were generated by the support and development teams focusing on continuous improvement activities
   
3. support ticket backlogs are higher than the team would like

My observations on these are:

1. the year over year decrease in ticket volume is great progress and validates our hypothesis that we had issues that could be overcome. It also makes me ask the question why can't we reduce an additional 30%, 40% or even more?
   
2. the idea that the amount of person hours savings was the first thing presented by the team confirms that the team has clearly and decisively transitioned from "fire fighting" to a value add team that is focused on making our applications more supportable
3. while support backlogs are higher than the team would like (we did reduce the team size quite a bit) the focus on collaboration, continuous improvement and root cause analysis should not decrease. The long term gains that we see from these efforts (see bullet 1 above) are much greater than any short term blips in support ticket volume increases, especially when we collaborate and communicate effectively with our sponsors and users

Needles to say, both of these initiatives have led to interesting findings on how we perform application support and development and will definitely help us think about how to improve in these areas going forward....and I will keep blogging about it as we progress.

Where do solutions come from?

about 1 year ago | Mark Mintz: Mark Mintz

I am working on an initiative that is looking to improve the way we engage with our key, front line users when developing IT solutions. Our key user base is highly mobile, global and has very little discretionary time. To be effective and widely adopted, the solutions we deliver need to have clear value propositions, need to be easy to use and generally not require big behavioral changes. Given the complexity created by all of these factors I think we have done a good job in identifying value add solutions that can help these users be more effective and efficient. With that being said, I do believe that there are opportunities out there that remain untapped. The reason being, in my opinion, is due to the way we engage with these key users: typically somebody has an idea for something that might be a good product and then we follow it up with a period of user research validating how that idea could be implemented. I think this approach works but we can improve on it by finding new, different and better ways to source the initial solution ideas. The way we are trying to do this is by listening to our users. Not by asking them questions about a specific product idea but by listening to them talking to each other, sharing ideas, tips and tricks and advice and asking questions of each other. From this we hope to get insight into how they work and the types of issues they face and put ourselves in a position to identify simple solutions that have the potential to help these users. Success is an active community of users openly discussing the things that they do on a daily basis and the tools and techniques they use. With this dialog should come valuable insight into how our users work and what helps and hinders them. Its exciting stuff and has the potential to provide us with a wealth of knowledge that will hopefully lead to greater value for our users. Needless to say I am excited by the challenge and look forward to blogging about what we're learning and the progress we are making. Any feedback would be great....just leave a comment.

Top software development books

about 1 year ago | Mark Mintz: Mark Mintz

Jurgen Appelo at noop.nl created another great list...the top 50 new software development books. The list includes books covering various aspects of software development: project management, business analysis, user experience, testing, refactoring, agile practices, architecture, web services, etc. The list was created using a weighted list of the following criteria and includes books that are less than two years old...

• Number of ratings on Amazon.com
• Average rating on Amazon.com
• Number of ratings on GoodReads.com
• Averate rating on GoodReads.com

Note: The time that has passed since a book's release date was part of the calculation. For example: A book that got three 5-star ratings in just four months is listed higher than a book that got the same ratings in a much longer period of time

The power of really good software - part II

about 1 year ago | Mark Mintz: Mark Mintz

My exploration of SugarCRM continues. Being impressed with what the application could do we decided to explore if it could meet the requirements of another stakeholder group. This required an even deeper dive into the application and I must say that even after taking this dive, I am still impressed with the application!! First off, let me start with what is really cool about open source. I was able to download this application, get it installed and not only try it out but dig through the code, the web services API and just about every aspect of the application. This makes the decision to proceed with an implementation much less scary because you can get a far deeper understanding of the application than any sales demo could provide. So, what did my digging turn up...well, one of the key requirements was to be able to email into the application and have those emails tracked against the Contacts that were included on the email. After reading the documentation, which is just as good as any vendor product documentation I've ever read (and once again I had access to it without having to spend a nickle), it was clear that the out-of-the-box application did not do what I needed to do. My next step was to search through the plugins and open source add-ons to see what I could find. I did find a Connector that could be integrated into our Lotus Notes client but it was to intrusive for our liking. The next option was to write a script that could read emails from a mailbox and load those emails into SugarCRM. This looked like a good option so I dug deeper. This digging led me to the SugarCRM SOAP API. This is definitely another area where I was impressed. My first thought, however, was to be very scared because I read quite a bit about SOAP and SOAP based web-services and I was expecting quite a challenge. Far from it, while dealing with the SOAP Message response objects took a little figuring out, calling the API via my Ruby script was fairly easy (I'll do another post on the power of Ruby and SOAP, following this one). The API has get_entry/set_entry methods that more or less let you create and search for any record in the application. Getting a hang of these methods basically allowed me to do everything I needed to do....and also made me think of a ton more things I could do if only I had the time! All-in-all I am thoroughly impressed with SugarCRM and more importantly I have changed the way I think about evaluating vendor applications. Having the ability to run an application through it's paces (both technically and functionally) without the need for sales reps, contracts, etc....is definitely a new requirement that I will add to my list of vendor selection criteria in the future. My guess is that this will lead me to many more open source applications!!

The power of really good software

about 1 year ago | Mark Mintz: Mark Mintz

I am doing some research into SugarCRM and I am absolutely amazed how simple it is to install, configure and use. SugarCRM is an open source CRM package and according to their website:

SugarCRM is rethinking how technology can help companies manage customer relationships. Sugar, the market leading commercial open source CRM application, delivers a feature-rich set of business processes that enhance marketing effectiveness, drive sales performance, improve customer satisfaction and provide executive insight into business performance. Supported by deep collaboration and administration capabilities that adapt to how your company operates, Sugar is delighting customers of all sizes across a broad range of industries.

The need that we are looking for SugarCRM (or any other similar application) to fulfill is to track interactions with a set of people. This is obviously a very small subset of what SugarCRM can do. As a result, the goal of my initial evaluation was to see how easy it would be to get a simplified version of the application in front of key stakeholders and get some feedback on whether we thought it was worth proceeding. In less than 1 hour, I was able to download the entire application stack (Apache, MySQL and the SugarCRM application) and get the application up and running locally on my workstation. Of the hour I spent, these simple steps took about 10 minutes, of which approximately 5 minutes of that was spent waiting for the software to download. In the remaining 50 minutes I was able to login, get a pretty good feel for how the application functions and actually configure the screens and tabs users see and add and remove fields on screens. None of my time was spent reading documentation or user manuals. Instead I was immediately adding value: making changes, testing them out and then making some more changes. Configuration changes are simple drag and drop exercises and saving and deploying changes is as simple as pressing the "Save and Deploy" button. Understanding how to use the application was just as easy and within minutes I was adding data and navigating around the application with ease. All in all, the experience was an absolute pleasure and I believe that after that 1 hour of work I have a good enough sample that I can share with stakeholders to figure out how to proceed. What a great example of software done right!! And the best part....it's FREE!

Impact of the economy on PMs

about 1 year ago | Mark Mintz: Mark Mintz

Josh Nankivel at PMStudent.com created a survey that asks participants

What impacts on project management (in particular) have you seen from the state of the economy?

A slightly revised version of my initial response below:
In the world of software development within enterprise IT, with less money available for projects, teams are asked to do the same or more with less....less money, less people, less tools, etc. The PMs who will be the most successful in this climate are the ones who do more than just manage. Those that can lead, inspire and motivate, those that can innovate, those that can break down barriers and remove impediments, those that can teach and mentor and make others better, those that can pitch in and code or test or prioritize requirements or help solve problems when necessary, those who can get stuff done by building empowered and enabled high performing teams will succeed.....come to think of it, these are the people who will also be most successful when the economy is strong!

Interview questions for software developers

about 1 year ago | Mark Mintz: Mark Mintz

Jurgen Appelo, CIO at ISM eCompany and author of the NOOP.NL blog, posted a list of 100 interview questions for software developers. The list includes questions grouped by knowledge areas like Requirements, Project Management, Testing as well as Functional Design, Technical Design, Construction, Data Structures and Algorithms so it should apply to PMs, BAs, Scrum Masters and Product Owners as well as Developers and Architects.

Going through the questions and thinking about how I would answer the questions was an interesting exercise that I would recommend for others. Some of my favorite questions:

1. How do you treat changing requirements? Are they good or bad? Why?
2. What do you do with requirements that are incomplete or incomprehensible?
3. Can you name the responsibilities of the user, the customer and the developer in the requirements process?
4. How can you reduce the user's perception of waiting when some functions take a lot of time?
5. Which tools are essential to you for testing the quality of your code?
6. What measures have you taken to make your software products more easily maintainable?
7. What can you do reduce the chance that a customer finds things that he doesn't like during acceptance testing?
8. How many of the three variables scope, time and cost can be fixed by the customer?

Refactoring as a learning exercise

about 1 year ago | Mark Mintz: Mark Mintz

Over the last several months I have been trying to add a new tool to my tool belt by learning Ruby, Ruby on Rails and RSpec. After completing some tutorials and other basic programming tasks I was looking for something else to further develop my skills. Not having any great ideas for new applications I turned to our SVN repository and the code base for an application that I was functionally familiar with. My goal was to look through the code base, understand what was going on and see if there was anything that I could refactor. I figured this would be a good way to learn from real world code. This code base is for a new, greenfield project and was developed with good RSpec coverage so it was a good candidate because the code was likely in good condition and it would really challenge me by stretching my Ruby and Rails skills. As I dug around I found some things that were of interest and possible candidates for refactoring:

1. In trying to understand what one area of the code was doing I looked first to the RSpec tests. After reading the tests and then the code the tests were testing I realized that the tests were created at a higher level and as a result it was somewhat hard to infer the behavior of the code under test
2. In that same area of the code several Model classes had quite a bit of hand written SQL code. Portions of the SQL was dynamically generated and as a result it was somewhat difficult to understand what was actually going on. I knew functionally what this area of the code was supposed to be doing but it was not totally clear from reading the code what it was actually doing

This was the opportunity I was looking for...could I figure out what was going on, refactor the code to better leverage ActiveRecord without having to write custom SQL and get the proper results at the end? Having a goal and learning opportunity in place here is what I did:

I started by writing my own RSpec tests at a lower level of detail. The existing tests tested higher level methods that called several lower level methods, did some calculations and returned a result. The new tests I wrote started by testing the lower level methods individually. This had two benefits: (1) I could get a better understanding of what each of the lower level methods were doing and (2) I could refactor each method individually and have tests that would ensure I was not breaking anything at the lowest level of detail. This was by far the slowest part of the exercise because I needed to work through much of the handwritten SQL to be able to understand what was expected from these methods so that I could write the tests. After several hours of walking through the code and testing out SQL's against the development database I had what I thought was a decent handle on what was going on so I created my first test and verified that I was able to get it to pass with the existing code. My next step was to then figure out how I could replace the hand written SQL with ActiveRecord API calls and retain the same functionality. The first place I started was with the ActiveRecord find_by Dynamic attribute-based finders. The first challenge I faced was that the handwritten SQL's had several joins that I needed to deal with. To be able to deal with these joins I added some associations to the appropriate model classes and began to dive into getting the right :group, :include and :conditions options to return what I needed. This was an amazing learning exercise in Rails and the power it possesses. Finally, after several more hours of trying different things on IRB I got something that seemed like it could work. During my research however, I bumped into the ActiveRecord Calculations module. Considering that the main goal of the SQL's I was trying to refactor was to sum column data I thought perhaps the sum method would be an even better option. After several passes through IRB with the sum method I found what I was looking for and lucky me, my first test passed. From this point on it was more of the same with 5 or 6 additional methods until I got to a point where all of the hadwritten SQL was replaced by ActiveRecord API calls and I had a set of RSpecs that tested each method individually, including the higher level method that calls all of the lower level methods. Having made it this far and feeling pretty good about the results, I identified some next steps to keep the learning going:

1. complete the same exercise for the remaining model classes where similar hand written SQLs exist
2. look for areas where I can extract duplicate code across all of those models into single, re-usable methods or classes
3. work on refactoring the RSpecs to improve their performance. Currently they feel a bit slow due to, what I suspect, are the many database interactions that are happening
   

So for those of you that have actually read this far down, here is what I learned:

1. Refactoring is a great way to learn about a programming language. If you are new to a language try finding some existing code, write some tests for it to get an understanding of what it is doing and then refactor the code while getting the tests to pass.
   
2. Using TDD or BDD makes learning about a programming language easier
   
3. ActiveRecord is a powerful tool that gives you a great way to interact with a database without having to write SQL
   

Blog list for developers

about 1 year ago | Mark Mintz: Mark Mintz

For those looking for good blogs to keep you up to date on software development check out the Top 100 Blogs for Developers (Q4 2008). According to the author...

...the list is meant to cover software development in a broad sense, which includes project management, process improvement, agile development, requirements, design, coding and testing.

There's even an OPML version of the list to make subscribing to these blogs as easy as importing the list into your favorite RSS reader!!

Improving application support

about 1 year ago | Mark Mintz: Mark Mintz

We have a standard 3 level support model with the first and second level being part of a general support organization and third level being a part of a separate development organization. In this model support requests come in and are assigned by a Day Manager to the appropriate group for that application. From there requests get escalated through the levels if the lower level cannot address the issue or satisfy the request. We have had this model for quite some time and now we are facing some issues that are impacting the quality of service we are providing to our end users. The two biggest issues that we are encountering are:

1. lack of ownership for end-to-end support: as requests bounce around from level to level and organization to organization there is not clear ownership for getting issues resolved. Finding out when issues will be addressed requires emails back and forth between teams which means delays and finger pointing which ultimately results in unhappy users.
   
2. lack of commitment to knowledge building and continuous improvement: our focus has been mainly on fighting fires and there has not been enough focus on building the knowledge of team members and improving processes over time to be able to perform more effectively and efficiently.

Here is what we are doing to address these issues:

1. lack of ownership for end-to-end support: we are going to be testing a new "touch and hold" support model. In this new model we plan to flatten out the three levels into individual groups: one for operational requests, one for issue resolution and one for requests for data and adhoc reports. Instead of requests escalating from one level to the next until it gets to somebody who can resolve it our goal is to get the request to the right person or group of people upon receipt with no need to escalate. By doing this the person that gets the request should be the right person to address the issue and therefore there is no need for escalation. If that person requires assistance there will be technical and functional advisers available to assist but the initial recipient of the request still owns the request and is responsible for coordinating a timely resolution with the advisers assistance. In this model support engineers that receive support requests are empowered to reach out to users for clarification and negotiate services and resolution times, especially for complex requests and issues
   
2. lack of knowledge building and continuous improvement: each group in the new model should have a set of key metrics that indicate performance. I expect the groups might have some of the same metrics and some unique metrics individual to the group. For instance the operational group might have a metric based on average time to closure while the issue group might have a metric based on percentage of issues resolved or operationalized. The goal would be to use the metrics to ensure that each group is focusing on the right level of improvement and knowledge building. Additionally, we plan to build capacity into these groups for these tasks. Improvement and knowledge building take time so we need to accommodate for that time.
   

Focusing on these areas should result in more timely and accurate resolution of support requests resulting in more satisfied users and reduced support costs. I'm sure it will be an interesting experience as we progress through these changes.....I'll continue to blog about individual aspects as we move ahead. In the meantime if anybody has any experience with implementing a similar model please leave a comment and let us know how it went.

Been there done that....time to move on

about 1 year ago | Mark Mintz: Mark Mintz

I totally agree with Jay Fields in that I too prefer jobs that allow me to learn new things. Exhibit A - My Career:

1. Started working on as a analyst on a mainframe GL package
2. Moved to PeopleSoft HR implementations (PeopleSoft HR was THE HR application at that time)
3. From there moved on to BI/Reporting with Essbase (before Hyperion and Oracle)
   
4. My next stop was an internet company building a custom Java based billing application (not sure why we didn't leverage the companies existing Oracle Financials for this but that is for a different post)
5. When it came time to move on I went back to HR systems and then from there back to Finance applications....each time I focused on a different technology and functional area within the broader spectrum of Finance and HR

Some people might view this approach to my career as being a "jack of all trades, master of none" since I did not stick around long enough in any one of the areas to become a true expert in any one of the technologies or functional areas. I beg to differ. I believe that I gained two valuable things from this career track:

1. A broad range of experiences and skills that I can draw on when moving into new areas
2. The ability to learn new things quickly, figure out how much I need to learn in that area to be effective and then move on to the next thing I needed to learn

I also totally agree with Jay when he says:

Think of it as job security -- I shouldn't ever be out-of-date when it comes to technology experience. Think of it as an investment -- everything I learn creates a broader range of experience that I can leverage for future projects or jobs. Think of it as experimenting -- by trying many different solutions I may find ways to combine them and innovate.

I also think this type of career keeps it interesting. I can't imagine how unhappy I would be if I was still focusing on the same stuff I did at the start of my career. I've done that stuff, learned a lot and moved on. I've got that tool in my tool belt now and it's time to get some more tools. If I ever need to come back to that tool, sure it may need some honing but a hammer is still a hammer and I should be able to get the job done, even if the hammer is an old model.