The Blog

Product packaging

published September 17, 2010

I have to admin that I have become an Apple fanboy. Usability and design of their products is just so good that it is quite hard not to like their gadgets. First impression is very important for us humans and we make snap decisions about product quality based on that impression. For Apple products, high quality starts from product packaging. All their packages look and feel something with a high quality.

There is much we should learn from Apple. First of all, I feel that too many software projects do not achieve top-notch usability and are producing mediocre user interfaces. Secondly, designs lack eye candy, which is something that Apple products definitely have. Many projects are in desperate need of an artistic web designer, who could take full responsibility of usability and high quality UI design. When this person does not exist, role is cast upon developers, which will in turn deliver mediocre results.

There seems to be a wide skill gap between a software developer and a web designer. Software developers are not very interested in usability and consider it somewhat secondary. Web designers have artistic creativity but have no interest in coding. As Scrum suggests, we should have a cross functional team but unfortunately in many projects team is just too homogenous and lacks artistic creativity. This creativity gap is then filled by buying layouts and mock-ups from web design companies.

This is like hiring two teams: a “visual team” and a “development team”. Of course, these two teams will not meet in person, and they only “communicate” with document handovers. Sounds crazy? Well, it is. These unnecessary handovers can distort product vision and hinder team from owning the visual plan. Much better option would be to hire a web designer and ask him to join team as a full-time member. I believe that this leads to better usability, finer architecture and less confusion about product vision.

Samuli @ 0:07 (2 Comments)

tags: Process, Quality

Trackback URL

Importance of a coach

published March 23, 2010

During yesterday’s morning exercise I once again realized importance of a coach. When you feel like giving up, you will need someone to kick your fat ass forward because you definitely can do one more. And then one after that. While sweating with weights, trainer kept pushing me forward. And push I did.

In IT projects we encounter same challenges. We have a defined process in place and we know what we should do but it is easy to cut corners and start slipping. To keep a team on a track, the process must be followed. If the process does not work, it must be redesigned. In addition, we must always try to move forward towards greater value and better productivity because if we are not moving forward, we are sliding backwards.

I know some teams that are doing “Scrum” but without daily scrums. I believe that this is a first sign of a lazy team. I also believe that a lazy team is not building a great product. If the team does not have a discipline to follow a simple process, can you realistically expect that the team is writing good unit tests and actively sparring a product owner? I do not think so.

So whose job it is to see that process is followed in Scrum? Thats right, it is yours, dear Scrum Master. You are the coach who is pushing team forward. It is your job to cheer for the team and keep pushing them forward.

Samuli @ 22:58 (No Comments)

tags: Process, Quality, Scrum

Trackback URL

Analysis of a successful project

published February 13, 2010

In a previous post I listed things that I consider important for a project to succeed. While writing the list, I constantly wondered how individual items are more of best practice, methodology and group dynamics related than expensive things you should buy.

A successful project must succeed in multiple areas. As seen on a picture below, there is no one magic bullet nor there is a one person making a successful project. It is a team effort and it will have to be started and managed accordingly.

In the picture above, there is an imaginary radar chart representing a project success on different categories. I think the items can be generalized into three categories: Execution, business and socials.

Execution contains actual implementation details, from methodology selection to coding, documentation and testing. Business contains business analysis, requirements,  calculations for return of investment, end users and other constraints. Sosials contains hiring a team, assigning roles for it and managing group dynamics.

So how do I come into this picture?
I usually work with roles such as “Scrum master”, “Technical Project manager”, and “Technical lead” and find myself working in all three sectors.

For people working in similar roles, it important to manage your own time and not to concentrate too much on one category. By concentrating too much on one area, you will cause damage for others. In the end, the success of the project is completely dependent on the skills of the people doing the job.

Samuli @ 19:26 (No Comments)

tags: Business, Customer, Group dynamics, Process, Quality

Trackback URL

When you absolutely cannot fail

published

Two days ago I had my wisdom teeth removed. It turned out that both teeth on my lower jaw were growing horizontally and their roots lied in the close proximity of nerves. In this case there is a small chance of nerve injury during the surgery. Luckily, everything went as planned, thanks to professionals who knew how to do their job.

Of course in these cases you will want absolutely the best people on the job. Last night before the surgery I wondered what is a IT equivalent for this case, what do you do when your project absolutely cannot fail?

For this exercise to be reasonable, we have to give us some constraints. First of all, we cannot use multiple teams to do same job in parallel. Secondly, we cannot prolong implementation forever.

So what are the ingredients?

Hire a team

• Hire professionals.
• Hire people who are enthusiastic.
• Have variation in team.
• Hire people who are hands on.

Goal

• Have clear vision what you want to accomplish.
• Have clear goals and scope.
• Communicate vision clearly and often.
• Ensure that solution fits into overall strategy.
• Ensure that everyone involved knows your vision and goals.
• Ensure that project has senior management support.
• Calculate ROI.
• Know the problem solution solves.

Business requirements & constraints

• Know business requirements.
• Know availability requirements.
• Know anticipated user loads.
• Know non-functional requirements.

End Users

• Engage users early.
• Test high fidelity prototype with end users.

Team roles

• Project Leader; A Person who provides solid leadership for the project and manages it.
• Architect; A Person who is responsible of the architect and who also writes code.
• Tester; A professional who ensures quality with other team members.
• Developers; People doing design and coding.
• User interface designer; A person who is responsible for actual user interface design.
• User interaction designer; A person who will be making interaction design for the UI.
• Product owner; One person, who prioritizes backlog and knows vision inside out.

Methodology

• Use agile methodologies to deliver value in short iterations.
• Have clear definition of Done.
• Know your velocity.
• Continuous improvement using retrospectives.
• Do not let technical dept to pile up.
• Have a prioritized backlog.
• Have a release plan.
• Release often.
• Start up with minimal product.
• Use TDD.
• Use Personas.
• Have architecture guidelines and follow them.
• Have a coding standard.
• Develop an high fidelity prototype first.
• Have slack.
• Work closely with business.
• Work at sustainable pace.
• Have project status up-to-date and visible to everybody.
• Do pair programming now and then.
• Do formal design reviews.
• Do formal code reviews.

Technology

• Use proven technology.
• Use productive technology.
• Do not use just released versions of products.
• Beware of product/framework hype.
• Minimize used technologies.
• Know used technologies inside out.
• Focus on quality code.
• Do not let code clutter.
• Have clearly defined architecture.
• Use a Bug tracker.
• Use Version control.
• Write as little code as you have to.
• Implement vertical slices early.
• Keep it simple.
• Focus on rich domain model (Domain Driven Design).
• Do POCs when in doubt.
• Use set based design.
• Use static code analyzing tools.
• Use a profiler.
• Use Continuous Integration.
• Use a memory analyzer.
• Implement risky things first.
• Refactor when needed.
• Use design patterns.
• Buy tools you need.
• Have identical development, test and production environments.
• Use a web speed tester.
• Use caching.
• Focus on clustering early on.
• Make deployments as fasts as possible.

Documentation

• Have up-to-date documentation of core components.
• Use wiki.
• Document all implemented user stories.
• Document architecture from different perspectives.

Automation

• Automatize installations.
• Continuously automatize manual tasks.

Testing

• Have comprehensive test suite.
• Have unit and automatic acceptance tests.
• Test all documented user stories.
• Test performance early.
• Test security early.
• Do exploratory testing often.
• Test synchronization often.

Project management

• Keep it simple.
• Develop an initial project plan.
• Gather and analyze data.
• Manage risks.
• Know your budget.
• Do not micromanage.
• Keep meetings in minimum.

Group dynamics

• Believe in yourself.
• No part time members.
• Have team take ownership of solution and time estimates.
• Make the Quality a team effort.
• Celebrate success.
• Develop an enthusiastic and quality focused group prototype.
• Develop a learning environment.
• Share information.
• Minimize turnover.
• Develop a positive group affective tone.
• Develop a stop and fix culture.
• Collocate team.
• Have private and cozy workplace with enough room.
• Have good working conditions.
• Protect the team from outside disturbances.
• Make work fun.
• Coach team.

Huh, that was a long list and I am sure I forgot something.

Samuli @ 19:15 (No Comments)

tags: Quality

Trackback URL

How to create products customers love

published December 3, 2009

Yesterday I finished reading book by Marty Cagan “How to create products customers love” and I recommend it for team leaders and for everyone working in product owner or project manager roles. Book is about product management and Mr. Cagan is stating that custom software (consulting) is running by somewhat different rules. Still, there are much to learn from the product business that directly applies to consulting.

I discovered product management through Poppendiecks’ book “Implementing Lean Software Development: From Concept to Cash“. Their message is that custom software world should learn from how great software products are built. I totally agree.  In the product world, customers’ problems and product vision must be very well understood and communicated by a product manager. In my experience, the custom software world is doing these two things often poorly.  A Lot of custom development in corporate settings is done for internal applications and I think that the concept of customer is somewhat vague.  In my opinion, the ultimate customers for the internal applications are end users and I do not see them very often involved in the building of those applications.  Good product managers are hard to find and in corporate settings customer project manager is often working as product manager and “proxy end user”. In reality these are all different roles and they require different skill set. If you throw in the fact that customers in general do not know exactly what they want, you find yourself in “regular” consulting project.

Agile methods attack this issue by delivering value incrementally so that results are seen after every sprint and correct solution is built. However, I feel this very thing is working as a excuse for not having a clear vision for a solution, which is absolutely a must in product world. This is something that a good product managers understands. In the end, successful consulting projects need competent people from both customer and integrator.

Samuli @ 19:17 (No Comments)

tags: Lean, Quality

Trackback URL

Strangling legacy code

published November 30, 2009

How do you refactor a legacy module which is used by many clients? Well, you strangle it. In a picture below we have two clients using some legacy code that we want to get rid of.

You start by creating a new interface and switching part of the usage to that interface.

Gradually, you refactor parts of your legacy code and move more clients using the new implementation.

In some point, you have managed to move all usage from the legacy interfaces to the new implementation, but you still might be using the legacy implementation under the hood.

The final step is to completely remove legacy code once you got all your necessary features refactored.

And actually delete all your legacy code, I do not want to see huge code blocks commented out “just in case we need this in the future”. You don’t. And if you do, you still find it in your SVN, right?

Samuli @ 22:46 (No Comments)

tags: Java EE, Quality

Trackback URL

Differentiating between bugs found in a quality control and those delivered to a customer

published

In our software delivery process at the current customer we end our sprints to a production release. This is a very nice way to keep iterations compact and to minimize huge testing effort before deployment. So, how do we keep track of the bugs that are found inside a sprint by our own quality assurance and those that are shipped to the customer in the new release? We use custom issue types for Jira.

We create the bugs found inside the sprint as “notices” and the shipped bugs as “bugs”. This way we can easily keep track of how our quality control process works, what is the ratio between the notices and the bugs, and to track exactly how much time is spent on a bad quality. This important data is later used in sprint planning to make sure we have reserved enough time to fix notices before the next production deployment. This is a must if you want to release quality software at the end of every sprint.

Samuli @ 21:10 (No Comments)

tags: Process, Quality, Scrum

Trackback URL