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.
Agile project ramp up
published May 6, 2010
The current project I am participating started without ramp up and the whole team was brought on-site right from the beginning. Now, 2 months after the start, I feel that some kind of team ramp up would have been useful. We started the project without a real product backlog, architecture plan, wiki or bug tracker. First two sprints were pretty much filled with infrastructure work, initial architecture design, backlog work, and the “normal sprint 0 stuff”. Still I feel uneasy.
Do not get me wrong, our customer is really good and in my opinion, doing lots of things right. But I think that we would have been better off had the project been started only with a team member and a scrum master. Then say after 3 sprints, rest of the team would have been invited to the party. I feel that in the beginning there are too many obscurities to fully utilize whole team potential and unnecessary waste is generated.
Also, Scrum.org’s Scrum guide says:
The ScrumMaster works with the customers and management to identify and instantiate a Product Owner.
But for my current project, it was other way around.
One could argue that by inviting whole team from the start, each member will know project history from the beginning which will help them grasping social representations among other things. Also by ramping up the team, you will unintentionally divide the team to “old-timers” and “newcomers”, but that will hardly be a problem because team is still very much forming and open for the newcomer innovation. During ramp up period there would be time to get product backlog started and initial prototypes/mock-ups made.
What do you think, do you ramp up your agile projects?
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.
World domination plans
published February 23, 2010
A minimal working product. These words seem to be very hard to grasp, I do not understand why. There is a study by the Standish Group, which claims that 45% of software features are never used and 19% are used only rarely. “This is something that we won’t need now, but will need it in the future”, I hear all the time. This kind of thinking is also very strongly present in RFQs (Request for Quotation). I call these world domination plans. A plan to build the greatest service from scratch and release it in a one big bang. “Not gonna happen”, I say.
Start with a minimal working product. This does not mean a crappy web page with animated GIFs and scrolling texts. No, it means a simplest thing that fulfills the most critical needs. Establish a constant flow of new important features, minimize a lead time, and listen your customers. This is how you build the greatest services.
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.
Differentiating between bugs found in a quality control and those delivered to a customer
published November 30, 2009
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.
The architecture that could not work
published November 29, 2009
I had an interesting conversation with our architect about dysfunctional software architectures and their impacts on projects developed on those architectures. I have seen some overly complex software/enterprise architectures that just make simple things too difficult. When project is started to build solution on dysfunctional architecture, it is very hard for it to fill customer expectations and to be productive enough. Sure, every architecture will have its weak points but I am talking seriously flawed ones here. Simplest reason for a dysfunctional architecture can be lack of a architect role for a platform or maybe he just is not competent enough. However, you might have company’s “best architect” on team and still have rough time.
Where did these non-functional requirements came from?
Some harder cases we have encountered are the ones where customer wants to make architectural decisions that will affect whole platform. If these decisions are not sound, we are headed for trouble. Software experts might get instantaneous architecture smell, but it might be hard to pinpoint exactly what problems proposed solution will cause in the future or why it will not work. You get gut feeling that everything is not right here. In these cases it is very important to find out why customer will want to affect architectural decision and to steer discussion towards business requirements behind these ideas. You should never build solutions technology ahead, always discover business needs beneath and design best technical solution for it. It is very important not to commit yourself once you get the smell.
Validating archtecture beforehand
In smelly cases, try to build a proof of concept and experience exactly how it will not work. As stated above, this can be hard without POC. Of course it also could work. To fully explore all possibilities, set-based design (read more here) can be used.
What if customer is so in hurry that there is absolutely no time for a POC? Then I would try to prepare for problems and design system so that flawed parts of architecture are isolated with anti corruption layer, which is easier to refactor later.
Once work has started
It is hard to change foundations of software/enterprise architectures even if everyone sees that selected architecture does not work as planned. We as humans have a tendency to decide a way to solve a problem and keep investing into it, even if correct action would be to discard it and start over. Too often we will not want to admit a mistake. In addition, there can be lot’s of organizational politics behind this. Usually, in these sad cases, money keeps pouring in…
Keeping your development environment in sync with production environment
published
In one of my current projects, we are developing a semantic portal that is providing welfare related information for public. Portal content is updated daily by content providers while we are developing more features using three week sprints. We have a very nice way of keeping development environment in sync with production environment.
1) In the beginning of every sprint, production content is copied into the maven repository using custom made scripts.
2) Test environment data is brought up to date with the production environment.
3) Development environment content data dependency is updated to latest version in our pom.xml files.
4) Developers update their environments from the SCM and the Maven repository. Development data is now in sync with production data.
5) Developers start to build new features planned for the current sprint.
6) Once a feature starts to be ready, new installation is made into the test environment and a developer will make necessary configurations for it.
7) Tester works with developer to finish the feature. In our team, tester is a role and can virtually be anyone.
8) Test environment content is copied into the Maven repository using custom made scripts.
9) Development environment content data dependency is updated to latest version in our pom.xml files.
10) Developers update their environments from the SCM and the Maven repository. Development data now contains just finished feature.
11) Steps 6…10 reoccur n times.
12) Once all features are ready (or we run out of development time), testing begins. During this time, only bug fix commits are allowed as we are getting ready for the production release update.
13) Production deployment is made for the new release.
This cycle works well and this way we are developing against latest production data. Key here is to make export and import scripts very easy to use. This style will help you tremendously if you are planning to release after every sprint.
Subscribe to RSS feed
The Tag Cloud
Agile Business Coaching Coding horror Conference Customer Design of Experiments Future Group dynamics ITIL It should not be that hard Java EE Kanban Leadership Lean Liferay Methodologies Natural UI Performance tuning Process Productivity Quality Retrospective RIA Scrum Six Sigma Social psychology Software Software architecture Testing This is great TOGAF
WP Cumulus Flash tag cloud by Roy Tanck and Luke Morton requires Flash Player 9 or better.
Samuli's Links
The Blog Archive
January 2013 (1)
February 2012 (1)
January 2012 (1)
November 2011 (1)
June 2011 (2)
May 2011 (1)
April 2011 (2)
March 2011 (2)
February 2011 (1)
January 2011 (1)
December 2010 (1)
November 2010 (1)
October 2010 (3)
September 2010 (3)
August 2010 (5)
July 2010 (2)
June 2010 (3)
May 2010 (4)
April 2010 (2)
March 2010 (6)
February 2010 (7)
January 2010 (3)
December 2009 (7)
November 2009 (6)
