The Blog
How to measure team productivity?
published May 26, 2010
Imagine this. Team A is producing 500 lines of php code per sprint whereas team B is producing 400 lines of Java code per sprint. Sprint length for the team A is 3 weeks, team B is doing two week sprints. In the team A there are 5 developers and one tester, team B consists of 4 developers. Both teams are “scrum mastered” by same person. Which one of these teams is more productive?
I have given lots of thoughts to team productivity and to systems and processes that could reliably measure it. Today, I finished reading Leading Lean Software Development and found a very nice gem from it on the page 235, where authors discuss about productivity.
First they state that there is no good definition for software productivity. Software development is rarely the goal of a system but a way to solve a customer’s problem. Therefore, measurement of function points and lines of code is irrelevant and the real productivity should be measured from value provided to the customer.
This is very powerful stuff as I have many times witnessed how a project is measured against a-year-old-and-out-of-date project plan which is pretty crazy. What is the value we are providing to a customer? How much value are we providing per developer? These are the questions we should be asking.
So, was team A or B more productive?
Social representations in IT project
published April 12, 2010
Social representations theory is a popular European social psychology concept by Serge Moscovici. Social representations can be defined as commonsense knowledge about general topics that are the focus of everyday conversations. It is something that can start as a abstract thing like “social media” and then people are gradually starting to understand it by anchoring it to old information. This is something that we encounter also in IT projects, especially at the start. Customer old timers have loads of social representations about the business in form of acronyms, services and requirements that e.g. consultants entering the project cannot be aware of. You know that you have encountered a new social representation when you get a confused feeling while the customer is talking about an important ‘thingy’, but you have no idea what that ‘thingy’ is. Don’t worry, we all get that feeling.
I feel that the start of a new IT project is like a wobbly sphere. Project team is forming, people are encountering new social representations, requirements are emerging and architecture is evolving. The key here is to implement first version of the software architecture and a working vertical slice. Team leader should focus on forming social representations about the goal, requirements and the architecture by referring to these artifacts only with one business related term, so that team can use common language about abstract, software-related concepts. If there are no architectural social representations forming, I suspect that software architecture is a mess.
You also might have have noticed how agile movement has formed it’s social representations about scrum master, product owner, pigs and chickens. Everyone shares common knowledge about these things but we all also have our own personal beliefs and experiences about the very same things. Other key element in the new project is to ensure that team members share somewhat compatible social representations about important things with each other and with the customer. If Scrum means different things to different people I would suspect team to encounter more surge during storming stage of group development.
The rush of starting a new project
published March 5, 2010
I started a new project this week. It seems that customers are rising the bar for consultants, since this contract needed a solid CV, passed psychological tests, and a successful interview with the customer. Luckily I got the job and there is always something special in starting a new project. The feeling of beginning to build something great is always a pleasant one. Technologies this year seem to be circling around JEE, SOA, Liferay, Javascript, and Open Geospatial Consortium standards, such as WMS and WFS.
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.
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
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)
